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PREFACE 


This handbook is an attempt to document the techniques of using a 
|j current version (Model 13) of the compatible time-sharing-system (CTSS) 

| which has been developed at the MIT Computation Center. It is primarily 
I 1 ® anual °f how to use the system, in contrast to many of the research 
'f nemos , which have been more detailed in their documentation pf the 
I techniques of implementation. Because CTSS is basically a system which 
j wil1 allow an evolutionary development of time-sharing while continuing 
\ to allow more conventional background systems to operate, it is ex- 
| P ected that the present manual will of necessity be revised many times 
\ bef° re if reaches a final form. A good deal of the difficulty arises 
j f lom > on rhe one hand, the rather drastic change in user operating 
techniques which time-sharing permits, and on the other hand the immense 
| amounc of programming required to fully implement the system. 

The present work, although not highly polished, is being presented 
now to assist in this evolutionary process. It is expected to be a 
supplement to the Computation Center’s Procedures Handbook which ex- 
plains many of the general administrative details of the Center. 
Furthermore, a knowledge of programming is assumed of the reader. It 
has been our objective to present to an experienced programmer a 
reasonably complete manual which will allow him to use wisely the 
present version of the time-sharing system. 

Because of the rapidity with which many of the features are being 
implemented, and the delays in distributing the inevitable revisions, 
some features are described here which are not yet accomplished. The 
reason for this is that it was felt to be important to indicate the 
intended scope and objectives of the system so that individual users 
could plan ahead in their applications. The features which are not 
implemented will be found listed in an appendix which will be revised 
Periodically. In addition, each of the chapters can be expected to be 
(periodically revised. 

Since the present work is primarily a handbook, no attempt has 
been made to make any comparisons with the several other time-sharing 
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and remote-console efforts which are being developed by groups else- 

| 

where. The only other general purpose time-sharing system known to be | y r . 
operating presently, that of the Bolt, Beranek and Newman Corporation i oren 
for the PDP-1 computer, was recently described by Professor John =3 of t 

McCarthy at the 1963 Spring Joint Computer Conference. Other time-sharis Korn 
developments are being made at the Carnegie Institute of Technology with J Denr. 
a G20 computer, at the University of California at Berkeley with a 7090/ Mrs. 
at the Rand Corporation with Johnniac, and at MIT (by Professor Dennis) t o t 
with a PDP-1. Several systems resemble our own in their logical 
organization; they include the independently developed BBN system for and 
the PDP-1, the recently initiated work at IBM (by A. Kinslow) on the the 

7090 computer, and the plans of the System Development Corporation with test 
the Q32 computer. 

: to 1- 

To establish the context of the present work, it is informative to CTS5 
trace the development of time-sharing at MIT. Shortly after the first 
paper on time-shared computers, by C. Strachey at the June 1959 UNESCO of t 

Information Processing Conference, H. M. Teager and J. McCarthy at MIT ! Bruc 

delivered an unpublished paper "Time-Shared Program Testing” at the us c 

August 1959 ACM Meeting. Evolving from this start, much of the time- add, 

sharing philosophy embodied in the CTSS system has been developed in prog 

conjunction with an MIT preliminary study committee (initiated in 
1960), and a subsequent working committee. The work of the former par 

committee resulted, in April 1961, in an unpublished (but widely circu- Res* 

lated) internal report. Time-sharing was advocated by J. McCarthy in sys 

his lecture, given at MIT, contained in "Management and the Computer of 
the Future (MIT, 1962). Further study of the design and implementa- 
tion of man-computer interaction systems is being continued by a 
recently organized institute-wide project under the direction of 
Professor Robert M. Fano . In November 1961 an experimental time- 
sharing system, which was an early version of CTSS, was demonstrated 
at MIT, and in May 1962 a paper describing it was delivered at the 
Spring Joint Computer Conference. 

As might be expected, the detailed design and implementation of 
the present CTSS system is largely a team effort with the major portions 
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3 f it being prepared by the following: Mrs. Marjorie M. Daggett, 
l [r _ Robert Daley, Mr. Robert Creasy, Mrs. Jessica Hellwig, Mr. Richard 
'orenstein, and Professor F. J. Corbato. Important contributions to some 
]of the commands and the background system have been made by Mrs. Lynda 

J Korn. Valuable criticism and advice has been offered by Professor Jack 
Dennis, Mr. J. R. Steinberg, and members of the Computation Center Staff. 
Mrs. Leslie Lowry, Mr. Louis Pouzin, and Mrs. Evelyn Dow have contributed 
to the preparation of the commands. 

Special credit is given to Professor Herbert Teagcr for the design 
and development of his Flexowriter control subchannel which allowed 


the original experimental version of the present system to be developed, 
tested, and evaluated; only with such an opportunity was it possiole 
to have the confidence to make the present pilot development of the 


CTSS system. 

We should also like to extend our thanks to the Computer Center 
of the University of Michigan where Professor Bernard Galler, Mr. 

Bruce Arden, and Mr. Robert Graham have been very helpful in advising 
us on the use of their Mad Compiler in our time-sharing system. In 
addition, Mr. Robert Rosin kindly made available the Madtran editing 
program for processing Fortran II subprograms to Mad subprograms. 

We should further like to take this occasion to acknowledge 
partial support by the National Science Foundation, the Office of Naval 
Research, and the Ford Foundation, of the development of our present 
system. We also add our appreciation for the support provided the 
Computation Center by the IBM Corporation. 

Finally, we should like to encourage the readers of this handbook 
to examine the present system with a view toward improvements, and we 


shall welcome such criticisms . 


F. J. Corbato 


Cambridge, Massachusetts 
May 1963 
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teaching machines; language learning problems; library retrieval; text 
editing; algebra manipulators; and many more. 

The Compatible Time-Sharing System (CTSS) is a general-purpose 
programming system which allows a new form of computer operation to 
evolve and yet allows most older pre-time-sharing programming systems 
to continue to be operated. CTSS is used at a console which may be of | 

eral varieties, but which in essence is an electric typewriter. Each 
console user controls the computer (i.e. as seen by him) by issuing | 

standard commands, one at a time. The commands allow convenient per- 
formance of most of the routine programming operations such as input, 1 
translation, loading, execution, stopping and inspection of programs. 

This command convenience, although it has a fixed format, is with no 1 

loss of generality since a command can also be used to start an arbi- 
trary programming subsystem with its own control language level. 

The consoles of CTSS form the foreground system, with computation 1 
being performed for the active console users in variable -length bursts, 
on a rotation basis, according to a scheduling algorithm. The back- 
ground system is a conventional programming system (slightly edited for 
the time-sharing version) which, at the least, operates whenever the 
foreground system is inactive, but which may also be scheduled for a 
greater portion of the computer time. The entire operation of the com- 
puter is under the control of a supervisor program which remains 
permanently in the 32,768 word A-bank of core memory; all user programs 
are either kept in the 32,768 word B-bank of core memory, or swapped in 
and out of the disk (or drum) memory as needed. 

Not only are the active user programs swapped in and out of the 
two secondary memory disk modules (4.6 x 10® words each) and the drum 

words) but it is expected that all console users will utilize 
the(disk memory for semi-permanent storage of their active program and 
data fries. Cards and magnetic tapes will still- serve in secondary 
roles as long-time and back-up storage device); they will be usable in 
CTSS only through the central Computation Center facilities and not 
directly through the remote user consoles. I 
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HISTORY, PLANS, AND CURRENT STATUS OF SYSTEM 

Initially an experimental time-sharing system was developed using 
the special three-Flexowriter subchannel designed and built under 
H. Teager's direction. The first public demonstrations of this system 
were in November 1961, and the work was reported at the Spring Joint 
Computer Conference in May, 1962. During the latter half of 1962, in 
addition to refinement of the initial system, studies were made of how 
to remove several limitations in the system, namely: 1) the limited 
number of typewriter console stations, 2) difficulties of installing 
and maintaining remote connections, 3) lack of compatibility of opera- 
tion with other 7090 programming systems, and 4) problems of information 
retrieval and information security associated with a large on-line 
secondary memory. 

These studies resulted in plans for the conversion of the experi • 
mental time-sharing system to a pilot system which would be capable of 
operating simultaneously with most of the work load already handled by 
the 7090 at the Center. These plans for the 7090 included: 1) the 
implementation of the interrupt clock, memory protection, and relocation 
features; 2) the addition of an IBM 7750 communications channel which 
allows up to 112 Teletype consoles to be attached via phone lines at 
remote locations; 3) the addition of a second bank of 32,768 words of 
core memory; 4) the installation of the IBM 1301 disk file; and 5) the 
design and programming of a master disk control subroutine (memo CC-196) 
and an associated disk editor program (memo CC-208) for flexibility in 
using the crucial secondary memory. As separate experiments, two smalle 
computers are being specially attached to the 7750 channel by telephone 
line links; the Electrical Engineering PDP-1 is to be used as an ex- 
perimental display console, and the Civil Engineering IBM 1620 will be 
used to control remote analog input-output equipment such as a pen 
plotter. All of the above equipment and attachments should be installed 
by spring, 1963, and the necessary programming adaptation required for 
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first pilot version of the time-sharing system is expected to be com- 
pleted by summer, 1963. In fall, 1963, the addition of an IBM 7320 
aoderate-speed drum should further increase system performance by 
illowing somewhat faster secondary memory access and transmission speeds 
:or swapping programs in and out of core memory, although the drum 
lemory capacity is limited. At this time the general performance of the 
r090 will be improved by upgrading it to a 7094 Model 1. 

To implement effective operation of a pilot time-sharing system, 

;he initial 16 Teletype consoles have been deployed as follows: two 
:onsoles for the Center system programming staff to assist in implementa- 
:ion and evaluation; one in the programmer consulting office to allow 
•apid assistance to users in the location of errors; one with the Center 
;eypunch operators for service keypunching directly into the disk 
lemory; one for the 7090 computer console operator; one for the 7090 
;ape-mount operator; one in Professor Minsky's research group for their 
ipplications and system evaluation; one in Professor Corbato’s office 
:or analysis, monitoring, demonstrations, and programming purposes; one 
lore remotely located at Professor Miller's Civil Engineering Computation 
.nstallation ; and seven in an open pool for general time-sharing users 
it the Center. 

One of the principal design features of the pilot system is that 
lost older pre-time-sharing systems may be operated in the role of a 
lackground program simultaneously with the foreground time-sharing console 
system (memo CC-202-1). Because of the weakness of input-output memory 
irotection in the 7090, it was necessary to develop an intricate input- 
Jutput analyzer-monitor program for safe operation of older programs 
vhich had been developed without time-sharing in mind. Besides easing 
the programming transition problems of changing from batch processing 
to time-sharing techniques, this compatibility feature eliminates the 
necessity for immediately satisfying all of the Center's 400 research 
nsers (and a similar number of student users) with the initial version 
3 f the time-sharing system. 

To achieve programming compatibility, the time-sharing system uses 
the same programming languages normally available in the major Center 
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system, FMS : Fap, Mad, and Fortran in the form of the nearly 
equivalent Madtran (memo CC-188). Initial requirements dictated 
special core -memory -only versions of these compiler programs, but 
this restriction is being eliminated. 

To contrast with batch-computing techniques, it is informative to 
summarize a typical time-sharing usage. A user has written a subprogram 
in a compiler language and wishes to incorporate it into his set of pro! 
grams already developed and kept in the central disk file. After sittij 
down at a console, he first gives a login command to identify himself, i 
His next command, input , turns his console into a pseudo-keypunch. Usii 
simple conventions, he types in his subprogram for storage with other 
subprograms on the disk. If he should note any typing or logic errors : 
in his new file, now or at any later time, he can correct the file 
using an edit command. (If he wanted to avoid the tedium of typing a 
long program, a suitably trained keypunch operator could just as easily 
have done the operation in advance.) Using an appropriate command the 
user can compile his subprogram, and if he has no diagnostics requiring 
correction, he can prepare to test it. Using the load command, he 
collects in core the newly compiled subprogram in binary form, any sub- 
programs previously prepared, and the necessary library subprograms 
drawn from as many libraries as he wishes. If loading is successful, 
and does not require re-entry for the addition of missing subprograms, 
a start command initiates his program. He notes the results (if any) 
that he receives, and after stopping the program, if necessary, inspects 
the status of various locations and variables within the set of subpro- 
grams loaded. After a suitable amount of probing he detects his 
> programming error, makes the necessary corrections, and continues in th: 

manner until he wishes to terminate the session by giving a logout 
command . 

To the above basic time-sharing system, which consists presently 
of a few dozen commands, many new features and additional commands must 
added before it will be generally acceptable. Among the more important 
ideas are the ability 1) to request from the consoles large-scale delays 
printing or punching of programs and cards at the central Center facili 
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S j) to create delayed graphical plots at the Center; 3) to allow 
foreground-initiated jobs to be run as background after a user leaves 
j iis console; 4) to assign by user request, for the duration of a console 
ession, various input-output units, such as tape units, from the common 
entral pool; 5) to allow inter-user console communication for activi- 


subprograj ties suc ^ as mana £ ement games; 6) to be more flexible and versatile in 

_ s 1 -he allowable debugging techniques such as traces, interpreters, selec- 
set of pro- L 

; t ive dumps , and so forth. Specifications for some of these features are 
^ l 6 r s i l l ^ y 

> iescribed in later sections. 

In addition to the obviously heavy programming development required 
Jfor the above improvements, there are large operational questions which 
ill need to be determined in the areas of reliability, error detection, 
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programming system and hardware maintenance under conditions of near- 
continuous operation, automatic traffic and performance monitoring, and 
automatic accounting. 

Finally, in the areas of hardware, there are evaluations to be 
made of the various consoles: the various model Teletypes, especially 
models 28 and 33, the Kleinschmidt 311 Teleprinter, the IBM 1050 
Selectric typewriter, as well as possibly others. Vast questions lie 
in the area of self -maintaining display consoles, and finally questions 
of improved high-speed drums and future memory hierarchy schemes will 
need to be studied. 
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CHAPTER 3 


GENERAL DESCRIPTION AND USAGE TECHNIQUES 


ground system is organized around commands, which each 5ecc 
user gives at his console, and the user’s private program files which ] 

ept on the disk. For convenience, the format of the disk files is 1 con£ 
such that they have titles with name and class designators. (Files can " tat 
en ered from cards or punched out at disk editing time.) 

The Supervisor ^ aS 

wait 

e supervisor program remains in A -core at all times when CTSS is line 

Its ,u " ction “ ^ - «.p.t 

. “" S ° SChedull "8 «f console -in ilia ted (foreground) and off- of m 

e-initiated (background) Jobs; temporary storage and recovery of I "dea 
programs during t he scbeduled swapping; „ 0 „i t ori„g of all input and |.he 
output from the disk, as well as input and output performed by the bacXen 
ground system; and performing the general role of monitor for all I 

oreground jobs. These tasks can be carried out by virtue of the I same 

.hilhTt? “ ireCt “ ntr01 01 811 trl “ P * -ost crucial of | = che, 

is the one associated with the Interval Timer Clock. Ipr.s; 

Ev Val Tlmer Clock is set for a small quantum of time, q Imaner 

ru 1 IaCOn ‘' S thS S “ P " VISOr o»» Interrupt the program currently^ Ib.ckg 
ruling in e-core in order to accept input from the consoles or to issue! » re 
utput to the consoles. If the input from a console is other than a 1 the s 

command line, it is left in the supervisor.s core buffers until it is | 

ea y the user's program (whether a command or a user-written p,og,am)| £ — 
the input li„„ is a command, it is given immediate priority and I 

supervisor, after dumping as much as necessary of the current B-cor. | 

“ ” dlSk ’ brl ” SS la ** ™ ™ program from “ 

I tion, 

each rn r f :V hl I lnitlal tOP Pri ° rity ’ the “sharing programs are! 

cording to th T ° f tlmS WhlCh 13 S ° me mUltiple of 1 determined ac- f ^ f 
e sc eduling algorithm. At the end of each program's j 

appropriate time the supervisor determines which user is to L J n „ t \ 6 - 
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It must then determine whether the program or programs currently in core 
nust be dumped (to disk or drum), in part or entirely, to leave room in 
core for the next user. The next user must then be retrieved from 
secondary storage together with the proper machine conditions. 

In addition to maintaining input and output buffers for each user 
console, the supervisor keeps a record of the status of each user. The 
status of a user may be; working, where a program is ready to continue 
running whenever it is next brought in; waiting command," where the user 
has just completed a command line at his console; "input-wait” or "output- 
wait," where the program is temporarily held up waiting to get a console 
line in or out; dormant,” where the program has stopped running and 
returned control to the supervisor, but machine conditions and the status 
of memory are preserved for inspection, modification, or re-entry; and 
"dead, where the program has terminated, control has been returned to 
the supervisor, and machine conditions and the status of memory have 


:he back-I been scrapped. 
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It should be noted that command programs are handled in exactly the 
same manner as the user's own programs, with respect to status and 
scheduling. The background system is also considered another user; at 
present it has a different place in the scheduling algorithm, with per- 
manently lowest priority. In addition there will be another type of 
background, consisting of batch jobs initiated from consoles but left 
to run without console interaction; these jobs will be run with exactly 
the same type of scheduling as normal foreground programs. 

C ommand Format 

The commands are typed by the user to the time-sharing supervisor 
(not to his own program) and thus can be initiated at any time regardless 
of the particular program in memory. (For similar reasons of coordina- 
tion, the supervisor handles all input-output of the foreground system 
typewriters.) Commands are composed of segments separated by blanks; 
the first segment is the command name, and the remaining segments are 
parameters pertinent to the command. Each segment consists of the last 
6 characters typed (initially an implicit 6 blanks). A carriage return 
is the signal which initiates action on the command. Whenever a command 
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is received by the supervisor, "WAIT” is typed back. When the command j 

is completed, READY" is typed back. Where possible, the computer re- i 

sponses are in the opposite color from the user's typing. A command i 
may be abandoned at any stage, including during tho typing of the commai 

line or during command output, by giving the "quit signal" peculiar to 

the console. 


Command Initiation 

A user starts a command when he completes a command line at his 
console and is automatically placed in a wai ting com mand status. The 
time-sharing supervisor uses the interrupt clock feature every quantum 
of time to interrupt the user program being run and assign the users in 
waiting command status to a working status with an initial priority 
based on the size of the requested command program. 

Program Termination 

A foreground program leaves the working status by two means. It 
can re-enter the supervisor in a way which eliminates itself and places 
the user in a dead status; alternatively, by a different entry the pro- 
gram can be placed in a dor mant status (or be manually placed there by 
the user giving a quit signal). The dormant status differs from the 
dead status in that the user may still restart or examine his program. 

Inp ut and Output Wait Sta t e s 

User input-output is through each typewriter via the supervisor, 
and even though the supervisor has a few lines of buffer space available 
it is possible for a program to become input-output limited. Consequent 
there is an input-wait status and an output-wait status, both similar to 
dormant, into which the user program is automatically placed by the 
supervisor whenever input-output delays develop. When buffers become 
nearly empty on output or nearly full on input, the user program is 

automatically returned to working status; thus waste of computer time 
is avoided. 

Schedul ing 

In order to optimize the response time to a user’s command or 


10 





>« command 
-iter re - 
command 
the comma 
culiar to 


Urogram , the supervisor uses a multi-level scheduling algorithm. The 
l asis 0 f the algorithm is the assignment of each user program, as it 
Inters the system to be run (or as a response to a user is completed), 
o an 4th level priority queue. Programs are initially entered into a 


Jevel 4 corresponding to their size, such that 
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= [ log ( [ w / w ] + 1 ) 1 


(3.1) 


, here w is the number of words in the program, w is the number of 
P 

r 0 rds which can be transmitted in and out of the high-speed memory from 

he secondary memory in the time of one quantum, q, and the bracket 

^indicates "the integral part of". Ordinarily the time of a quantum, 

he basic time unit (currently about 200 ms.), is as small as possible 

ithout excessive overhead losses when the supervisor switches from one 

rogram in high-speed memory to another. The process starts with the 

time-sharing supervisor operating the program at the head of the lowest- 

4 

Level occupied queue, 4, for up to 2 quanta of time, and then if the 
program is not completed (i.e. has not made a response to the user) 

t lacing it at the end of the 4+1 level queue. If there are no programs 

ntering the system at levels lower than 4, this process proceeds until 

[the queue at level 4 is exhausted; the process is then iteratively begun 

4+1 _ 

again at level 4+1 , where now each program is run for 2 quanta of 

4 . 

time. If during the execution of the 2 quanta of a program at level 4, 
a lower level, 4', becomes occupied, the current user is replaced at the 
end of the 4th queue and the process is reinitiated at level 4 . 

Change of Program Size 


Similarly, if a program of size w^ at level 4, during operation 

requests from the time-sharing supervisor a change in memory size to 

w ", then the enlarged (or reduced) version of the program should be 
P 

placed at the end of the 4" queue where 


4" = 4 + [ log ( w "/w j ] 


(3.2) 


id or 
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Again the process is re-initiated with the head-of -the-queue user at j 
the lowest occupied level l' . I 

j 

Message Interaction Consideration s and Usage Times 

Because a user cannot "see" his program running, it is important ; 
that the programmer resort to appropriate cues and confirmation messages 
in his programming. Thus when input is expected, a good technique is 
to have the program first type out a message such as "type next data 
set or ’A=". Similarly after input it is often reassuring, if a long 
computation is required, to see some program output acknowledging the 
receipt (and perhaps the accuracy) of the input message. 

The reply response time is governed by the basic scheduling 
algorithm described earlier and depends on the number of other users. ; 
In the current implementation of the algorithm a user-computer inter- 
action consists of the period from an input message to an output 
message. Although the response time is only a few milliseconds if the 
user's program is already in core, whenever there is more than one 
user the usual minimum time for a response, which is the minimum com- 
puter usage time per response, is (in the current drumless system) 
approximately S/8 seconds plus the response computation time, where S 
is the number of program words in thousands. For example, eight differe 
user programs, of one thousand words each, could simultaneously respond 
within a second to input messages requiring only negligible computation. 

For those interactions which require non-trivial computation, the 
computer usage time is approximately given by the sum of two series, the 
first of which is for the computation: 


t - x< 21 1 > + i < i ) 


( 3 . 3 ) 


where the nth term of the series is that just necessary to complete 
the computation. As can easily be seen, in the limit of large compu 

the ratio of usage time to computation time asymptotically 
approaches one. 
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Storage Allocation 

Presently only one user program is kept in core memory at a 
•ime. However, in order to improve response time, as many user pro- 
grams as possible should be left in core memory. When required, as 
mch as necessary of the lowest priority program in the scheduling 
ilgorithm may be moved to the disk (or drum) memory to make more core 
lemory available. Because of the relative slowness of the 7320 drum 
L nd the 1301 disk transfers, moving program segments about in core is 
L n effective way to consolidate space into which to read the user pro- 
-ram next to be run. Thus the swap time required to give a response to 
user will be only that dictated by the size of his own program. To 
;arry out this procedure, several storage allocation algorithms are 
inder consideration. 

Although other possibilities exist, as in the Atlas Computer, 
Initially no attempt will be made to operate any user program unless 
ill of its program segments are contiguous and sequential in core 
nemory. Also the possibility exists of performing a look-ahead opera- 
tion of swapping a user program in or out while operating another user 
program (i.e., multiprogramming). Again, initially no attempt will be 
nade to implement the look-ahead feature, since the effectiveness is 
seriously reduced if scheduling changes (i.e., program completions) are 
frequent, or if there is frequent competition with the operating program 
for use of the drum or disk channel. 


(3.3) 


Memory Protection and Relocation 

To avoid fatal conflicts between the supervisor and multiple users, 

I the CTSS IBM 7090/94 includes a special modification which behaves as 
follows : 

Core memory is considered to be divided into 256-word blocks. There 
are two 7-bit protection registers which, when the computer is in its 
normal mode, can be set by program to any block numbers. Whenever a 
user program is run, the supervisor, as a final step just before trans- 
ferring to the user program, switches the computer to a special mode 
such that if execution of any memory address outside the range of the 
Protection register block numbers is attempted, the normal mode is 
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restored and a trap occurs to the supervisor. 

Inhere is also a 7-bit relocation register which modifies every 
memory address, during execution, by addition of the relocation registe: 
block number. ) Thus programs which have been interrupted by the super- j 
visor may be'moved about in memory, if necessary, with only the proper \ 
readjustment of the relocation register required. j 

Finally, if the user program, while in the special mode, should ; 
attempt to execute any instructions concerning input-output, changes ini 
mode or core bank reference status, or resetting of the protection or 
relocation registers, the normal mode is restored and a trap occurs to 
the supervisor program in core bank A. 

User Communication with the Superv i s o r 

(The supervisor performs a number of control functions which may be 
directly requested by the user. These include: all input and output 
(e.g., disk, drum, consoles, tapes); requests for information about or 
extension of the user program memory allocation; simulation of floating 
trap; control of each user's status, input level, and input mode; and 
other functions which involve communication with, or control by, the 
supervisor .") 

Since all protection violations cause a trap to the supervisor, a 
convenient means of user-supervisor communication is for the user to 
cause a protection violation; if the violation conforms to an establish* 
convention it may be recognized as a call to a subroutine in the super- 
visor. Since the supervisor is in A-core at all times, and since the 
user is in B-core operating in the protection mode, the following con- 
vention is used: 


L0C BCI 1 .NAME 

(or equivalently, TIA =HNAME) where NAME is the BCD name of the desired 
subroutine; the attempted transfer from B-core to A-core causes a pro- 
tection violation. 

In the future, should memory space in the supervisor region be 
available, some commonly-used library subroutines may be kept in this 
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supervisor call. 
rime-Used Message s 

Since usage time and computation time are different from real time 
the user may periodically want to know how much computer time he has 


lised He may request from the supervisor a message of the following 
lould f 


. form: 

anges in „„„ 

MIN. USED = 12.070 + 2.005 IN 24.011 + 5.725 

ion or 

In this example, the user has logged 2.005 minutes of computer time 
;urs to . , 

since he last requested a time message, which was 5.725 minutes (real 

time) ago; at that time he had used 12.070 in 24.011 minutes; he has 

now used a total of 14.075 minutes since he logged in 29.736 minutes 

a may be ago. Comparison of these sets of figures affords an estimate of his 
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rate of service. 

The time-request is made by typing in a special message at any 
level of console input; the message convention is initially set to TIME 
followed by carriage return. If the user wishes he may by use of the 
time command either change the time-request message to another set of 
characters or discontinue the facility altogether. 

Interval Timer Clock 

To facilitate running programs for a limited amount of time, the 

CTSS IBM 7090/94 has an interval timer clock available. This clock is 

completely under control of the supervisor; its action is as follows: 

location 5, memory A, is incremented in the units portion every 1/60 sec 

35 

whenever it overflows on a count of 2 , an interrupt occurs which, if 

the clock is enabled, causes a trap to location 7 and the trap location 
to be stored in location 6. 

('The supervisor uses this clock both for interrupting programs and 
for time accounting.^ Base -time and day-of -the-month information are 
obtained from the on-line printer clock. The supervisor can, however, 
simulate the interrupt clock behavior for each user . By supervisor 
calls similar to those of MITMR (memo CC-193), the user can program 
for nested interrupts and computation time readings. 
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Break Ch aracters 

Whenever a user types into his console, regardless of whether his 
program is running or not, the input character is received at the super 
visor level within 200 ms. The supervisor compares the character again: 
the break character list of that user. (In routine circumstances, and 
after every command, the break character list includes only the carriag* 
return.) The input character is added to the user's input message and 
if it is not a break character, no further action is taken. If the 
character is a break character, the message is called complete and one 
of several actions results. 

If the user input was at the command level (i.e., the user was in ' 
the dead or dormant status), he is placed in a waiting command status. ■ 
If the user's program was in an input-wait status, it is returned to 
the working status so that it may resume by reading the input message. 

If the user's program was already in the working status, the message 
is merely considered early and is left in the buffer for subsequent 
reading by his program. (If early messages continue to arrive and the 
input buffer area becomes nearly filled, a message is typed out to the 
user requesting that he stop typing until his previous input is read.) 

If a programmer desires to interact more frequently with input 
messages (including character-by -character reading) , any arbitrary 
break character may be added to and deleted from his break character 
list by means of subroutine calls to the supervisor. The programmer, 
however, should anticipate response time delays and the extra computer 
time usage for each interaction. 

Quit Signals and Console Input Level s 

When a user issues a command, two actions are initiated. First, 
his console input level is logically dropped from level 0 (command 
level) to level 1; second, a program is started (i.e., placed in working 
status), either the command program or his own, which executes until it 
terminates and enters dead or dormant status, or until the user manually 
terminates the program and places it in dormant status. Clearly this 
manual quit feature is desirable in that it allows the user to change 
his mind, correct mistakes, etc. The termination is performed by the 
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lether his 

ser 's issuing a single quit signal (varying with the console type) 
rhich may be issued even if the console is typing out. Upon issuance 

: the super- 

,f the quit signal, the user's console input level is raised by one, 

icter again: 

ormally back to level 0. 

nces , and 

In addition to this basic two-level scheme, it is possible for the 

he carriage 

ser to extend the number of input levels, thereby allowing for program 

ssage and 

ubsystems , each with its own control language (e.g., for debugging). 

If the 

'his is accomplished by the program giving subroutine calls to the 

e and one 

iupervisor, which on each entry drops the user console a level (to a 


imit of level 3). Whenever a quit signal from the console is received 

er was in 

>y the supervisor, the user's input level is raised by 1 (but no further 

d status. 

than level 0); control is returned (by means of a push -down list) to the 

rned to 

subsystem entry point previously assigned by the program to the current 

message . 

Level, or finally, after the right number of quit signals, to dormant 

message 

status . 

equent 

■a and 

Character Mode Switch 

-it to the 

For routine computer work, especially older applications, the 

read . ) 

lormal 7090/94 BCD character set is sufficient for console messages. 

input 

trary 

This set consists of 47 characters and blank, augmented by a few console 

control functions, namely: carriage return, tabulation, back space, 

iracter 

jrammer , 

color shift, delete-last-character, delete-last -message , and ignore; 

this normal BCD set is contained in a 6-bit code. When the character 

mode switch of a console is set to "normal'', a console will transmit in 

computer 

First, 

the normal BCD mode . 

The user's program, however, by issuing specific subroutine calls 

to supervisor entry points, may change the character switch to the "full” 
setting which, by means of a 12-bit character code, allows the user 

imand 

precise knowledge of console input as well as full flexibility upon 

in working 

output. Whenever a user program is completed and the supervisor is 

; until it 

receiving input from a console at the command language level, the charac- 

r manually 

ter mode switch is automatically restored to the "normal" setting. 

ly this 


change 

Consoles and Character Sets 

by the 

Each type of console attached to CTSS has associated input-output 
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mapping tables (Figure 3.1) for both the 6-bit and 12-bit character 
codes. (The high order 6 bits will be referred to as logical case 
bits.) In addition each console has a particular quit signal technique 
All characters are interpreted individually; hence any combination of j 
legal characters may be used in a message. In particular, the physical 
se is automatically kept track of on both input and output, so that 
the user need not program physical case shifts. 

In the case of 6-bit normal BCD mode input, characters which do 
not map into normal BCD characters or functions are enclosed in 
parentheses on the following chart and are ignored on input. The 6-bit 
normal BCD mapping is obtained by deleting the 6 high-order case bits. 
In a 12-bit mode input, all characters are coded and kept in a message. 

In the case of console output, in the 6-bit normal BCD mode, logica 
case 0 will be used, while in the full 12-bit mode, all characters will 
be printed as specified with unused codes being ignored. After all 
output messages, the console physical case will be restored to its 
previous case before output, except for the IBM 1014 and 1050 Selectric 
typewriter consoles, where lower case will be restored after output. 

When using Model 28 Teletype consoles, the quit signal is generate, 
by depressing and relasing the break key. There are no backspace or 
color shift functions available. 

When using the IBM 1014 Selectric typewriter consoles, the quit 
signal is generated by the sequence of: inquiry request, inquiry 

To initiate each line of input, the inquiry request key must 
be depressed. If the check light comes on from typing too fast, inquiri 
cancel must be given and the line reinitiated. Inquiry release acts as 
a carriage return signal. The color shift function automatically re- 
verses between input and output and is not codable. The only break 
character possible is carriage return. Type balls may be changed by a 
£hball command. It is not possible to input a non-printing message, 
hence when.it is desired to issue a carriage return with no message, the 

c aracter 71, which is always ignored, is issued before the carriage 
return. 


wh '° uslne “* Fle *°" rlt " ««•*«. t*. slgnal ls generatedi 
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f there is no output typing, by the following sequence: depressing 
d releasing "code delete" (a lever above the keyboard), followed by 
t car riage return. If there is output typing, instead the red button 
the control box in front of the keyboard must be depressed once. At 
resent these consoles are only implemented for a single break character 


so that carriage return, 
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Code Table Conventions, Figure 3.1 


In the columns for the appropriate console, the keys 
with the characters or control functions indicated, 
when depressed, generate a logical case and 6-bit 
code as a single 12-bit code. A keystroke causes no 
CTSS control action, with the exception of a break 
character or quit signal. In the case of the quit 
signal, no code is transmitted to the program. 

The character or control function corresponding to 
the logical case and 6-bit code in the columns under 
the appropriate console is typed out. If there is 
no character shown for the code, nothing types out. 



-bit mode 

input to 
he user 
rogram 


In either of the columns for the appropriate console, 
depression of a key with an indicated character or 
control function produces the corresponding 6-bit 
input code; if a character or control function is 
enclosed in parentheses the character is ignored and 
no input code is produced. In the case of the delete- 
character (d.c.), delete-message (d.m.) and quit signals, 
no code is transmitted to the user's program and in- 
stead the appropriate control action is taken. All 
other characters or control function codes are 
transmitted to the user's program. (The end-of- 
command character (e.o.c.) is generated by CTSS as 
a terminal flag to mark the end of the command 
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Figure 3.1 Console Input-Output Mapping Table 




output from 
the user 
program 


parameter list.) It is not possible to input to a 
program the codes for which there are blanks in the 
column labelled "7090 program input . " 

The character or control function corresponding to 
logical case 0 and the 6 -bit code in the column 
under the appropriate console is typed out. If for B lc 
a code there is no character or control function I he 
indicated in the column labelled "7090 program 8 

output, the code will be ignored; for uniformity B d. 

and future compatibility, it is recommended that 1 
the standard "ignore" code be used if this effect I 
is desired. 1 


Special Input Modes 

To anticipate noisy console lines, especially for future remote oi 
dialed connections, a confirmation mode will be available. In this moc 
every input message (i.e., up to the break character) will immediately 
be copied back as an output message. If a user detects a garble he i 

should issue a quit signal or take whatever action he has anticipated 
in his program. i 

When a person is working closely with his console at the command 
level, it will be possible to enter a brief mode. All programs which 
have been properly prepared will be able to interrogate the brief mode 
status indicator and to adjust the verbosity of their output accordingl 
Both the b rief and confirmation modes are set by the use of a command. 

Interconsole Messages 

Any user console can send a message to another user console by 
subroutine calls to the supervisor. These messages are placed in an 
input message pool for the receiving user along with the user number of 
the sender. The receiving user program can read its message pool at an 
time by a supervisor call similar to that for reading its own input 
console; an input-wait status can occur if no messages are present. If 
a receiver fails to read or aknowledge a message this is assumed to be 
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intentional. The user number of another console must be determined by 
supervisor subroutine calls which give the desired user number on the 
basis of the console location, problem number and/or programmer number. 
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'nis k Memory Control 

For a good understanding of the disk control subroutine, the 
following list of considerations concerning the use of the disk may be 


helpful . 


The user is able to write and maintain permanent program and 



data files on the disk. 

2. System programs (commands and standard library) are permanently 
recorded on the disk. 

3. The user has only symbolic reference to his files. 

4. The user is able to read and write many files simultaneously, 

and, for the sake of efficiency, may specify in which logical module a 

new file is to be written. In this way much unnecessary seek time may 

be avoided by using two separate modules for a simple read-write operation. 

5. The user is not able to reference any files not authorized to 


6. The user is able to initiate files in different modes, such as 
temporary files, permanent files, or permanent read-only files. 

7. In order to utilize the maximum storage capacity of the disk 
file and to be compatible with any future l.B.M. programs using the 
the disk, Format 1 (i.e., a single record per track) is used. 

A high level of user information protection can be achieved using 
the 1301 disk unit with the CTSS 7090. Complete protection is maintained 
(up to machine error and user identification errors) of all information 
on the disk unit. All users and systems use a single standard super- 
visor subroutine for reading and writing the disk. Because of the 
input-output trapping and memory protection features, mishaps will not 
occur if the user executes wild transfers, tries to store spurious 
information in the subroutine, or tries to execute explicit instructions 
for writing the disk. 

It is desirable, from the point of view both of programming and 
of disk administration, that the user have no notion of the absolute 
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ocation where his files of information are stored in the disk. Rathe- 
user will refer to his files only by symbolic names and logical mo< 
Furthermore, if the user does not specify the logical module 
will be assigned for him by the subroutine. Each of the 
es has two names; commonly the second name is descriptive of 
the type of file, as "FAP," "DATA," " B SS , " etc. Each name is at most 
sxx BCD characters long; the characters may be any alphanumeric charac- 
ters, but special characters should not be used; the special characters’ 
are used to distinguish the names of certain files created for the 
user by the supervisor. ; 

Normally different programmers on the same problem are treated as 
different users. To allow convenient cooperation between programmers 
such as students in classes or group projects, there is a feature which' 
makes it possible to have files common to several different programmers 
with the same problem number. To gain access to these common files 
(referred to by programmer number zero) a special supervisor call must 
be given which places the user in a "common file mode;" another super- 
visor entry allows the user to return to the normal "personal file 
mode." More elaborate cross-referencing of files can be accomplished 
by the link or copy disk editor control cards described in Chapter 5. 

Organization of the Disk Memory 

When the user initially requests use of CTSS in his Computation 
Center Problem Application Form he may also request the allocation of a 
number of tracks on the disk. If none are requested, an initial 
allotment will be made automatically which may later be extended by I 

request. The track allocation information is kept on the disk in the I 

master file directory of all users, which in addition contains the 

location of each user file directory. A track usage table is also 
maintained on the disk. 

Each user has on the disk a user file directory (UFD) which con- 
tains a 4-word entry for each of his files. The first two words contain 
He name and class name of the file. The third word contains the 
6 ° ^e file m the prefix, a document number (a number assigned 
internally to each file, for tracing and retrieval purposes) in the 







of printing, punched cards, or pen plotting, by the user s issuing 
appropriate delayed output commands. The output files must be stored 
by the user on the disk in appropriate formats. The delayed output 
commands initially will cause appropriate disk editor control cards t 
be generated by the supervisor and automatically inserted in the disk 
editing procedure; thus the delayed output occurs at disk editing tim 
The user can also by appropriate commands or supervisor calls generate 
other disk editor control cards to be entered into the disk editing 
process . 

Disk Editing Control Cards 

Periodically, requests will be processed by the Center Staff for 
input to the disk from cards and for output from the disk, either 
printed or punched. Control cards are submitted to the Center Dispatc 
Area which specify these requests. A variety of operations, specified 
by control cards, may be performed at disk-editing time, including, in 
addition to off-line input and output: editing of a binary program on 
the disk; deletion of a file, with or without punched-card dumping; 
changing the mode of files (in particular of "read-only class 2" files 
copying a user's file for another user; and linking several users 
(i.e., giving them access) to a particular user's file. 


Disk Reliability, Malfunctions and Recovery 

The 1301 disk memory is expected to be quite reliable - more so 
example, than tape - but to date enough information has not been 
gathered to offer any definite appraisal of its reliability. 

During times when CTSS is not in operation, the disk may on 
occasion be used by other systems. For this reason, as well as to 
protect information from loss due to malfunction of the disk, the con 
tents of the disk are dumped onto magnetic tapes as needed and at 
least once a day. These tapes are used to reload the disk at the same 
time that any requests for new input to the disk are being processed 

i 

Disk dump tapes are written in duplicate to safeguard against tape , 
errors. Dump tapes will be kept for backup purposes for several days, \ 
and a set of dump tapes will also be preserved from certain fixed point: 
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j the past (e.g. , week-old, month-old, three-month-old, etc.). Thus if 
jy information on the disk should be lost or garbled, any or all user 
ileS could be restored to the status of an earlier day. 

For example, were the entire contents of the disk to be erased, 
he last set of dump tapes would be used for reloading, and the loss 
onfined to less than twenty-four hours worth of new information. 

This is not expected to happen since erasure does not occur easily and 
he disk normally retains all information in case of power failure.) 

If both sets of duplicate dump tapes were to prove unreadable, the 
oss would be no greater than twenty-four hours, since the preceding 
ay's tapes would be available. If the dump tapes were being used to 
estore information after disk loss, and both sets of tapes were 
nusable (an unlikely concatenation of misfortunes), the loss would still 
e confined to forty-eight hours since an earlier day's tapes would be 
vailable . 

If an individual user's file is lost or garbled due to undetected 
allure of one or more disk tracks or to undetected tape error, the 
ingle file could be retrieved from earlier dump tapes either in 
arlier form or precisely, using the document number of the file for 
:onf irmation . If the user does not reference the file very frequently, 
towever, it is possible that he might not ascertain the error until, say, 
i week after the loss occurred, and it might not exist on any older 
>ackup tape. Consequently, as with every type of information storage, 

Lt behooves the user to take his own precautions concerning valuable 
'iles . 

Disk Editing Procedures 

Despite the rather large capacity of the IBM 1301 disk modules for 
secondary storage they are still capable of being filled by various 
Beans , from runaway programs to careless user file housecleaning. To 
Binimize the latter effect, each user is assigned an initial but 
usually adequate track quota, which can only be extended by a formal 
request to the Center. Furthermore a technique is used of automatically 
displacing, from the disk secondary storage to magnetic tape tertiary 
storage, those user files which have been unused and inactive for 
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several weeks. These tertiary storage tapes will be created in dupli 
cate each week and will be called history tapes . History tapes will 
automatically be erased after six months. No direct notice of file 
displacement will be made to each user; rather each user, upon 
examining his file directory, can by inspection see which files are 
still on the disk. Any attempt to use a displaced file will result in' 
a console message to the user. 

The above history tape procedure represents a compromise between 
automatic information disposal and the convenience of the user. The 
procedure which is illustrated in Figure 3.2 is done in conjunction 
with the normal disk editing procedures of dumping and loading the 
disk (at least daily). 



DISK INPUT CAROS 
( SAVED 2 WEEKS ) 

Figure 3.2 Diagram of Disk Editing Procedure 

The first phase of the procedure starts with the 7090 dump editor ! 
and 7090 dump control cards being recorded on magnetic tape via the 1401 
to run as a standard 7090 FMS job. The job first processes control 
card files left on the disk by the time-sharing supervisor, and then 
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the input tape control cards, before producing the requested dump tapes. 

In addition, the current history tapes are extended by the over-age 
files and any files which the user has asked to be deleted; correspon- 
ding file directory entries are marked along with the date dumped and 
the history tape position. Finally, the dump program produces an out- 
put tape for the 1401 of output requested by the dump control cards, 
both those submitted directly and those generated from consoles. This 
output consists of: BCD printing, BCD and binary cards, prefix-7 binary 
cards (for convenient and safe reloading of the disk), and those 
remaining control cards not acted upon which were produced at the 
consoles and left by the supervisor. The latter control cards, which 
may include requests to restore to the disk some files which have been 
displaced to the history tapes, are sorted for systematic retrieval in 
the next editing phase. Requested disk output of all forms will be 
kept at the Center for a period of only 2 weeks before being disposed of . 
During this time, it is the user's responsibility to pick up his 
output at the Center. 

The second phase of the procedure is that of loading the disk. 

The load -edit program is placed in the 1401 card reader, along with 
the control cards produced by the 7090 dump-edit program, as well as 
those load-control cards and input card decks submitted to the Center 
Dispatching Area. Input card decks, after they have been used by the 
edit program, will be placed in the Output Request Section of the Center 
and have a similar 2-week lifetime before disposal . By means of a 
special 1401 program, the above input is used to write a 7090 input 
tape which includes those files requested from history tapes. The 
latter is accomplished by the 1401 load-control cards produced by the 
7090, which log on the 1401 printer giving the 1401 operator detailed 
instructions on the mounting and dismounting of history tapes. Finally 
the 7090 load-edit program, with input data, is run as a standard FMS 
job, where the input edit data and the previous disk dump tapes form 
the input . 

The user will be able by a retrve command to retrieve his file 
from a history tape and replace it on the disk while at his console. This 
command will first give the user an estimate of the minutes of 7090 
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computer time required to position the appropriate history tape; if the 
user wishes to continue, the command will carry out the retrieval using 
the attach command; otherwise the user is free to create a 1401 load-edi 
control card such that the desired file will be entered into the disk at 
the next disk-edit period. , 

System Service Changes and Supervisor Messages 

Normally the CTSS system will operate for scheduled periods in 
blocks of time during each day. System operation will commence with ‘ 
messages typed on all consoles that are on (or can be remotely turned 
on and off) stating that the system is on and at what time the system 
will cease to operate again. 

When the CTSS system is shut down, either on a scheduled basis or 
an emergency basis, the following procedure occurs. Each active user 
jf; ceases to run, a cutoff message is sent to his console, all files are 

r Closed, all attached input-output units are disconnected, the user's 

j program is created as a file of name cutoff with class saved , the user 

is given a l ogout command, and a message is placed in the user's 
console message file on the disk giving a summary of the cutoff process j 
including the unread characters in the console input buffer. 

Whenever there are individual or general disk failures as well as 
system changes of great importance, appropriate messages will be placed 
by the supervisor in each of the user console message files. A console 
message file (named "MESSAG E.FILE”) is created for the user when 
necessary and is normally typed out by the login command, at which time 
it is deleted. During operation of his console, additional messages 
nay be generated; a user can read his console message file at any time 
with the print f command, which will not delete the file. The console 
message files, which are created by the supervisor, use disk tracks of 
the user's quota. 

For writing message files and for saving the user's program at 
the time of a system shut-down, the supervisor may have to take advantage f 
of the feature which allows an extension of the user's track quota (see f 

Organization of the Disk Memory"). In this event the user should, the | 

next time he is at a console, relieve this condition by dumping some of f 

i 
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if the B is files, or else older files will be dumped automatically for him at 
1 USing iL isk editor time. If at shut-down time the user himself has already 
load -edf J xc eeded his quota, no further extension will be allowed; his machine 
disk atft ta tus will be lost and so may his message. 

iL^ ignment of Input-Output Units 

I| There are numerous devices such as tape units, scopes, plotters, 
in M s atellite computers, etc., which are of such a nature that it is 

/ith “ Jdesirable to assign them to a single user for his session at his console, 
irned MThis assignment is done by means of an attach command, where the user 

stem Lay receive a busy signal whenever requested units are actively engaged. 

■Addressing conventions of input-output units will always be by logical 
is or j lunit numbers except when location is relevant. 

user I The supervisor will maintain for each user an input-output assign- 

are Lent table in which the logical -physical unit number interconnection 

r ' s j I will be kept. When a user gives a logout command at his console at 
user {the end of his session, all assigned units will be disconnected. 


Magnetic Tape Usage 

Although for a large number of cases the disk memory , because of 
its quasi-random access, is more appropriate for program data and 
[temporary storage requirements, there are still many problems such as 
payrolls, bubble chamber scanner output, etc., where magnetic tapes are 
more appropriate. This is true partly because of the vast quantities 
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of information. 

Within CTSS , the user may use private tape reels in the following 
way. The user types in an attach command specifying, for example, that 
file-protected private tape reel 103 should be mounted as logical tape 2 
on logical channel 2. The computer replies "WAIT," as the command re- 
quests from the supervisor pool an available tape drive. Upon receipt 
of an appropriate tape drive assignment, the attach command sends an 
interconsole message to the tape operator’s console (where his program 
is continuously processing messages), of the form: 


. the 


| "mount reel 103 as tape A3, file protected." 

f The tape operator, on completing the action, types "ok which causes 
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a confirming interconsole message to be sent back to the attach comma n 
can relay to the user the tape mounting information by j 
S the input information and concluding with "READY." 

Dataphones 

In addition to Teletypes, the IBM 7750 Communication Channel 

o?b°Ti? 01 hiS '“- <“«“• MOO bits/sec. ) by mean 

Bell System Model 2023 Dataphone sets, one a. the 7750 and anoth.t 

at the device, with a telephone line between the.. The devices <e . 

-1 computer or a 1620 computer) .111 appear as Input-output units', ' 

to „r r ’ ' r °'” hlS 0 °“" >la ' re,,UeSt to have logically attacl 

his program. Per convenience each device can be considered by the 

programmer to consist „ several logical subunits) in particular" tor 

con ro purposes one ot these subunits (e.g., the typewrite, keyboard) 

a„ represent a user console, so that auxiliary co „sole is not needs 

revision has been made Per error detection and transmission correction 

he internal character and message Peats, which are Purther des- 
cribed In memo CC-210. 

Command Programming i 

and plrZ 8 ”" ‘ CO " s » lli • '■>« command name 

and !h SeS " M ” *” Pl ‘ Ced lD ° rd " " * Par-eter list I 

n the corresponding co^and program Is located and started wherever 'i 

ro raT d lnl,lal commant 

S the Para ” et ° r Se *“ nts By Issuing supervisor calls 1 

comm T r eXC ' Ptl °” " ^ abOV,! Pr ° CeSS ° CCUrS * ith «» 

., ", ” thS f ° r “ t f ° r res u.ing program 0l „ hl ch has been I 

saved by the save command, is 




resume a p p 
1 2 


>• P . 
n 


in this case , just before starting ^ q ^ 

reordered to contain the sequence a p, P 2 ... p The purpose of 

~ 13 t0 all ° W the US6r 3 trivial way to develop and use private 
an s which can also be compatibly added to the general system. 

seful property of the command mechanism is the ability of one 

command to call another command. The setting of the* 

setting of the next command name 
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and parameter list is done by the operating command program issuing 
appropriate supervisor calls. 

By letting a command program set up an internal "command location 
counter" (not seen by the user), it is possible to run a master command 
program which in effect operates a "program" of subcommands, each of 
which returns to the master command after increasing the command location 
counter; the master command effects the return to the supervisor. The 
master command and the subcommands may, by means of a supervisor sub- 
routine call, modify the command parameter list. 

When this procedure is used, a fresh copy of the master command 
program is brought in each time it is executed , and the "command 
location counter" is used to dispatch control to the next command se- 
quence. Conditional branching can be realized by letting the subcommand 
increase the location counter by a variable amount. Communication be- 
tween subcommands must be accomplished by leaving data files on the 
disk. 

Console-Initiated Background 

Although the foreground console system is highly useful for 
preliminary programming, experimentation, and general man-machine 
interaction problems, there are occasions when long, uninterrupted com- 
putations must be performed by foreground programs. In these cases, the 
user ordinarily neither needs nor wants to occupy a console during the 
computation. To avoid this situation, it will be possible for the user, 
by placing his operating program in dormant status and issuing a bkgrad 
command, to turn his job over to the supervisor for operation as console- 
initiated background. In the bkgrnd command the user will specify as 
parameters: the computation cut-off time; the name of the job file; a 

name for the file to contain the final status of the program; and the 
name of a file for any console messages which may develop (including 
information concerning the final job status). 

After a console-initiated background program is turned over to the 
supervisor, the user, at a later time (even after he has issued logout 
and login commands), may interrogate the supervisor by means of a status 
command to obtain the status of his one or more jobs. From the status 
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command, the user receives a report containing: whether the job has 

shed or not, the time the job was submitted; the computer time used 
to date; the cutoff time; the current program level number; and the 
level populations in the scheduling algorithm. 

Estimate of Co mputation Completion Time 

When a user is present at his console operating a foreground pro* 
gram, he can easily determine the rate of computational progress by the 
use of the time command. However in the case of console-initiated 
background, estimation of completion time becomes a more difficult 
problem. For this purpose, an estimate command will be made available. 
Its properties are expected to be as follows; 

The console user gives as command parameters the designation of 
the particular background job in question, and the total expected 
computation time required by the job. The estimate command can determine 
the position of the job m the scheduling algorithm, and it has available 
a cumulative history of the scheduling traffic on, for example, an 
hourly basis over a period of a week. For each hour, the traffic 
history consists of a histogram, for each level of the scheduling 
algorithm, of the number of job initiations versus the total computation 
time required (including time in subsequent levels). Knowing in 
addition the current job status and the scheduling algorithm itself 
the estimate command is in a position to run a high-speed Monte Cario 
simulation, into future time, of the expected system behavior By 
running several such simulations, using different initial settings of 
the pseudo-random number generator, the estimate command can type out 
a message like: "Range of estimates over 3 trials = 131 min. to 237 min 
Estimated Completion time between 3:16 pm July 1 and 5:02 pm July l." 

<An alterna *ive message might be "job already completed.") 

If the estimated time is too long, the user will initially have 
no recourse except to cancel or stop the background job. Future i 

systems may contain priority alternatives, with additional usage charges ! 
serving as restraints. S ] 
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Backg round System Restrictions 

The normal user of CTSS will not need to concern himself with the 
following section which is primarily of interest to those programmers 
dealing with older pre-time-sharing programs. 

Certain programming conventions or restrictions must be followed 
in programs running as background jobs in CTSS. These restrictions 
are principally dictated by the need periodically to interrupt all 
programs operating in CTSS. Normally, well -programmed systems will 
already satisfy the requirements. What is required, in the main, is a 
program which is timing-insensitive (i.e., one which would operate 
correctly were the computer to be put in manual operation at any moment). 

1. The use of the following instructions is prohibited; if a 
system uses one of these instructions, a protection mode violation 
occurs and a diagnostic will be given. 

ECTM LPI 

ESNT LRI 

J2STM SEA 

ETM SEB 

LCH TIB 

2. Data channel traps on channels A and B will operate normally 
except that when a trap occurs, instead of an effective XEC of location 
13 or 15, control is transferred to location 13 or 15. Therefore, if 
data channel traps are expected, location 13 or 15 can only contain 

an unconditional transfer for proper program operation. (If this 
condition is not satisfied a diagnostic will occur.) 

3. The background system, if authorized by the Center, may use 
the Disk Control Subroutines (Chapter 5) by calls identical with those 
used by foreground programs. 

4. Since many foreground users may have programs operating, it 

is undesirable to have the operator intervene in the conventional manner 
to take terminal post-mortems. The "Load Cards” and "Load Tape" buttons 
are not to be used by the operator, since they reset the memory pro- 
tection and relocation mode. The "Start" button cannot be used because 
the operator does not know when the background system is operating. 
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However, in order that the operator may effectively perform these 
functions, the address of the console keys is continually checked by 
the Time-Sharing Supervisor. (The background system cannot use the 
address section of the keys.) When the supervisor finds certain codes 
it simulates the following functions: 

a. Depressing the "Load Cards" button. .j 

b. Depressing the "Load Tape" button. 

c. Depressing the "Start" button. 

d. Initiating the "standard error procedure." 

The standard error procedure” consists of storing the instruction 

counter in a specified location, and transferring control to some 

address which is the start of a post-mortem routine or a return to the 

background system monitor. The background system should therefore 

specify two locations for use by the Time-Sharing Supervisor. This is - 

done by the following call to a supervisor subroutine- 

* 

TSX DEFERR, 4 

PZS ERRILC, , ERRTRA 

where DEFERR contains: TIA =HDEFERR . DEFERR is the name of a super- 
visor subroutine which defines the error procedure. ERRILC is the 
address where the instruction counter will be stored, and control will 
be transferred to location ERRTRA . j 

5. GETTM is the subroutine used to read the date and time from 
the special Computation Center on-line printer clock. The original 
version of the program uses the "load channel" instruction (which is 

illegal), and is not interruptable . A new, interruptable version will j 
be available. 

The interval timer clock will be simulated for use by the back- 
ground system. This clock will only operate when the background system 
is in control and should therefore be used to determine the amount of 

time run. MITMR, the Center's timer program (CC-193), may be used 
in the normal manner. 

6. In general on the 7090, when an interrupt occurs, the inter- 
rupted program is resumed at the location specified in the appropriate 
lower core register. When the 7090 is stopped by an HPR instruction, 
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jje instruction counter is set to the next location; it is this location 
*hich is stored if an interrupt occurs. Thus if there is an interrupt 
t this point, the program resumes at the next instruction after the HPR. 
Since interrupts are a normal occurrence in the Time-Sharing System, the 
7090 cannot always be stopped by an HPR instruction. The HTR instruc- 
tion, however, produces a genuine program stop and should be used in 
place of the HPR. 

7. Only the following I/O units are available for background 

systems ; 

a. the card reader, card punch and printer; 

b. tape units A1-A6, A10, B1-B6 and BIO. 

| jf other units are referenced, a diagnostic will occur. 

8. The "Load Channel" instruction is prohibited. A diagnostic 
will occur if an LCHX instruction is used. A "Reset and Load Channel" 
instruction, if given, must immediately follow the select instruction; 
otherwise, the I/O check light will be turned on. An exception is made 
for three instructions; up to three SPR's, or SPU's, and/or NOP s 

may be inserted between the select and reset and load instructions . 

9. All I/O commands (including TCH commands) must have a "l" in 
bit position 20. This will automatically be done on assembly if the 
SCORE pseudo-op is used in the Center version of the Fap assembler. 

I/O instructions, if generated, must also contain this bit. A diagnostic 
will be given if this condition is not met. 

10. When the supervisor determines that the background system is 
to be saved while a foreground program receives attention, the 
background system's machine conditions must be saved. In order to save 
the status of an I/O channel, the supervisor must wait for current I/O 
activity to stop. If the background system reads or writes long records 
on tape, the time spent waiting in the supervisor can be detrimental to 
the foreground response time. It is normally required, therefore, that 
all physical records read or written on tape be less than 1000 words. 

If this condition cannot be met, the matter should be discussed with 
the Computation Center Staff. 
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IX. To ensure insensitivity to timing, proper interlocking of 1 
I/O commands and the CPU program must be guaranteed, usually with TCO}| 
instructions. iVhen this is not done, it is sometimes possible to getf 
erratic program operation due to the probabilistic nature of other prqji 
gram interrupts (and consequent program delays) occurring during the * 
operation time of I/O commands which change the working data area of M 
the interrupted program. This also applies to control-card coding. S 
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SUPERVISOR SUBROUTINE CALLS 

Th e subroutines listed belo. are available to CTSS users through 
t6 . supervisor prograd; a brief description of their function follows. 
The entries to the disk control subroutine are also via the supervisor, 
the function of each of these entries is described in Chapter 5. 


Supervisor Subroutines 
KDFLXA 
WRFLX 
WRFLXA 


dormnt 

(EFTM) 

(LFTM) 

GETMEM 

SSTMEM 

GETCOM 

AKNOLG 

TSSFIL 

USRFIL 

SETBRK 

SAVBRK 

GETBRK 

SETFUL 

SETBCD 

NEXCOM 

GETILC 

FNRTN 

INSTRT 

INPEND 


Disk Control Subroutine Entries 


.DUMP 


.ASIGN 

.WRITE 

.A PEND 

.FILE 

.SEEK 

.READK 

.ENDRD 

. RELRW 

.Cl EAR 

.DLETE 

. RENAM 

.RESET 

.FILDR 

.FSTAT 


I 
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Supervisor subroutines are called by means of the trapping con- 
vention described in Chapter 3, "User Communication with the Superviso: 
.Vhere arguments are expected, they are located relative to index 
register 4 as in normal calling sequences; for example 
TSX RDFLXA , 4 

PZS BUFF,, 4 

RDFLXA TIA =HRDFLXA 

is a call to RDFLXA with a single argument in (1,4) and a return to 
(2,4). The BCD name of the supervisor entry, as specified in the 
TIA instruction, must be lef t -justif ied with trailing blanks. 

To read an input line from the console, 

TSX RDFLXA , 4 

PZS BUFF 

reads 14 words into memory starting at BUFF. On return the logical 
J AC contains N where the break character is the Nth character; the 

word containing the break has blanks to the right of the break; 
subsequent words contain blanks. 



To issue an output line to the console, 

TSX WRFLX , 4 or TSX WRFLXA ,4 

P2E BUFF , , N PZE BUFF , , N 

where WRFLX writes the N words (N^14) starting at BUFF, adding a 
carriage return at the end of the line, and a color shift at beginning 
and end where the color shift is available; blanks are deleted from the 
end of the line. WRFLXA differs in that it does not add carriage return 
or color shift, and does not delete terminal blanks. 


All entries to the master disk control subroutine are interpreted 
like supervisor calls. See Chapter 5. 

The call ; 

TSX DEAD , 4 

returns control to the supervisor and puts the user in dead status, 
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machine conditions are not saved. 

1 . 6.1 

TSX DORMNT , 4 

^turns control to the supervisor and puts the user in dormant status, 
i-e ., machine conditions and the current status of the user’s program 
a re saved, unless a command is issued which causes a new program to be 
read into memory. If the start command is issued, control returns to (1,4) 

The call: 

TSX (EFTM) ,4 

causes entry into the floating-point trapping mode, with trapping 

simulated in B-core. 

TSX (LFTM) ,4 

causes exit from this mode. 

The call: 

TSX GETMEM ,4 

returns in the address of the AC the size of the user's current memory 

allocation. The call: 

TSX SETMEM ,4 

sets the size of the user's memory allocation to the value in the 
address portion of the AC. This subroutine must be used whenever the 
user wishes to increase the size of his program. If he fails to do 
so and refers to locations outside his original memory allocation he may 
not cause a protection violation, since the protection indicators are 
set by block count rather than word count; but dumping, when users are 
swapped in and out of core, is done by word count, and all information 
-stored beyond the memory bound will be lost. 

The call : 

TSX GETCOM , 4 

PZE N 

returns in the logical AC the Nth word of the user’s latest command. 

Each command issued by the user is written in the supervisor region, 

one word per argument, in an 18-word buffer; after the last word 

(the last parameter in the command line) a marker is written consisting 
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of a word of octal 7's. The command name itself is word zero, 


The call : 


TSX AKNOLG ,4 


BCI 1,* 

where * may be any console character (other than zero), puts the user 
in an input acknowledge mode; whenever a message is received from the 
console the specified character will immediately be typed out. To 
leave the acknowledge mode, the following call is given: 

TSX AKNOLG, 4 


The call : 

TSX TSSFIL , 4 

allows the user to read CTSS system files from the disk (e.g., the 
CTSS library). When in this mode only CTSS files may be read; to 
reset the mode, 

TSX USRFIL.4 

allows the user to reference his own files again. 

To drop the console input level (see Chapter 3, "Quit Signals 
and Console Input Levels") and set the corresponding quit entry point, 
the following sequence is used: 

TSX SETBRK.4 

PZE ILC 

which drops the input level by one and sets the return corresponding to 
the new level to the value of ILC. The call: 

TSX SAVBRK.4 

raises the console input level by one and returns in the AC the quit 
entry point corresponding to the level just left. If the command level 
(level 0) is reached, the contents of the AC is zero. The call; 

TSX GETBRK.4- 

returns in the AC the value of the instruction location counter at the 
time the user last gave the quit signal. 
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The call : 

TSX SETFUL ,4 

sets the console character mode switch to "full 12-bit mode. 

TSX SETBCD , 4 

restores the console character mode switch to "normal” 6-bit BCD 


The next group of subroutines have been designed for fairly special 
purposes; they are most likely to be useful for the writing of commands. 

The call : 

TSX NEXCOM , 4 

where the AC contains the name of a command, right-justified with 
leading blanks, puts the user in waiting-command status with the 
specified command as his next command. (This is used, for example, by 
the madtrn command to chain into the mad command.) 

The call : 

TSX GETILC , 4 

returns in the AC the value of the instruction location counter at the 
time when the user last entered dormant status. The call: 

TSX FNRTN , 4 

returns the user to dormant status; the user's instruction location 
counter is reset to the value it had when he last entered dormant 
status. (Both these entries are used by the pnr command.) 


ling to 


The call : 


IN3TRT ,4 


level 


t the 


I puts the user into console input mode. The contents of the AC is taken 
as a decimal initial line number; after adding ten to this number the 
supervisor prints it out; when a line is typed in it may then be read 
by RDFLXA. The supervisor continues to generate line numbers, incre- 
menting by ten. According to the conventions described under the input 
| command, (Chapter 7), a manual mode may be entered where the supervisor 
f suspends the generation of line numbers. To exit from the console input 
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mode the following call is given: 
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TSX INPEND.4 

(Both these entries are used by the input command.) 

Additional supervisor entries, to be added in the near future, wi£ 
allow the following requests: setting a break character other than thi 
normal one for the console; setting a character or set of characters 
which when typed by the user will denote a request for a time-used 
message; setting the input confirmation mode; requesting interconsole 
communication; calling adapters for the attachment of additional conso; 
units; requesting access to files assigned to other programmers with 
the same problem number; altering the increment used in automatic 
generation of line numbers ( input command); modifying by program the 
command parameter list. 
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CHAPTER 5 


USE OF THE 1301 DISK MEMORY 
Mas ter Disk Control Subroutine 

' The disk control subroutine may be considered an extension of the 
supervisor. It provides means whereby the CTSS user may store informa- 
tion on the disk for indefinite periods, such information to be 
completely protected and readily accessible for console and off-line 

reference . 

Each user is assigned one or more tracks to serve as a directory 
of all his private files currently stored on the disk. The directory 
consists of a set of 4-word entries, each of which contains a file 
name (two BCD words) and two control words indicating the type of file, 
the date the file was last used, and the address of the first track 
assigned to this file. If the file is more than one track long, a 
second track is chained to the first such that the first data word of 
the first track assigned to the file will contain the address of the 
second track. Additional tracks as needed are chained in the same 
manner. The first data word of the last track of a file will contain 
a pointer to the last word in the file. Additional tracks for the 
user’s private file directory may also be chained in a similar manner, 
if necessary. This chaining of tracks is done automatically by the 
disk control subroutine so the user will never need to concern himself 

with absolute addresses within the disk. 

The user may specify any of four modes for a file. The mode is 
designated by a prefix code in certain of the disk-routine calling 
sequences. The following is a list of the permissible prefix codes 
with their meanings: 

p Z E Temporary file, will be deleted as soon as it is 

read . 

PON Permanent file, can be read or altered indefinitely. 

PTW Read-only (class 1), can be read but not altered until 

the mode has been changed . 
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PTH Read-only (class 2), can be read but not altered except 

by edit cards submitted to the Center. Any attempt by 
a program to alter a file in this mode will cause a 
diagnostic comment to be printed. 

Temporary files will be deleted when the user gives the logout 
command. They are not included in his track quota, and he may use as 
many as he wishes as long as there are enough free tracks on the disk. 

All input and output for disk files is effected through the disk 
control subroutine. A set of entries is provided which are called like 
CTSS supervisor subroutines, i.e., by setting index register 4 and 
entering the subroutine by means of a TIA instruction (see Chapter 4). 

To dump a continuous block of core onto the disk as a file the 
following sequence is used: 

TSX .DUMP, 4 

*** FILNAM, ,MODNO 

PZH A , ,n 

where A is the location of the first word to be dumped, n is the number 
of words to be dumped, FILNAM is the location of the first of 2 consecu- 
tive BCD words which will become the name of this new file, and MODNO 
is the logical module number. Logical modules 1 and 2 will be available 
although only 1 is used at present. If MODNO is zero, the disk control 
subroutine will assign the module number. *** is a prefix code which 
defines the mode of the file. Upon completion of a dump operation, the 
new file name is added to the user's private file directory. 

To load a continuous block of core from a file previously recorded 
on the disk, the .LOAD entry is provided: 

TSX .LOAD, 4 

PZE FILNAM 

PZE A , , n 

where A,n, and FILNAM are of the same form as in the .DUMP calling 
sequence with the exception that n may be set to a larger value than 
necessary for loading files of indeterminate length. The prefix code 
and module number need not be specified. 
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For cases in which the .DUMP and .LOAD entries are insufficient 
(i . e ., the blocks of core to be read or written are not contiguous 
or are to be read or written in small units) a more versatile set of 
entries is provided. The first is the .ASIGN entry that prepares the 
system for the writing of a new file. (More than one file may be 
bitten at one time.) The calling sequence is of the following form: 

TSX .ASIGN, 4 

*** F ILNAM , , MODNO 

PZE WBUF1 , ,WBUF2 

where WBUF1 and WBUF2 are the initial locations of two 470-word blocks 
of core to be used by the disk control subroutine for the buffering of 
subsequent calls for writing. If available storage space is not 
sufficient for double buffering, WBUF2 may be specified as zero and 
only the single buffer specified by WBUF1 will be used. F ILNAM and 
MODNO are of the same form as described in the .DUMP calling sequence. 

The prefix code *** determines the mode of the new file and is as 

described under the .DUMP calling sequence. 

The .ASIGN routine assigns a free track, in the module specified 
by MODNO, to be the first track of the new file and sets the disk 
control hardware in motion to find this track. While the apparatus is 
looking for this track, the .ASIGN routine returns to the calling 
program which may then make use of the seek time. 

To write information into a file initiated by a call to the 
.ASIGN entry, any number of calls to the .WRITE entry may be used in 

the following form: 

TSX .WRITE, 4 

PZE F ILNAM 

PZE A, ,n 

Starting from location A, n words will be written into the file specified 
by F ILNAM. 

To write additional information at the end of an existing file, 
the following entry may be used in place of the .ASIGN entry: 

TSX .APEND , 4 

PZE FILNAM 

PZE WBUF1 , , WBUF2 
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which will locate the file specified by FILNAM and prepare to write 1 
starting at the end of the information already recorded. In other 
respects this entry is used just as .ASIGN. 

To terminate the writing of a file and free the write buffers for| 
other work, the following sequence is used: || 

TSX .FILE, 4 1 

PZE FILNAM I 

The .FILE routine will write out the last buffer load of the file 
specified by FILNAM with a pointer to the last word of the file. The 1 
user's private file directory is updated with the new file name. 

To initialize the disk control subroutine for reading a file 
from the disk, the following calling sequence is provided: 

TSX .SEEK, 4 § 

PZE FILNAM § 

PZE RBUF1 , , RBUF2 g 

where RBUF1 and RBUF2 are the initial locations of two 470-word blocks I 
of core to be used by the disk control subroutine for the buffering of I 
subsequent calls for reading. If available storage space is not sufficilt 
for double buffering, RUBF2 may be specified as zero and only the singlel 
buffer specified by RBUF1 will be used. 

The .SEEK routine will locate the file specified by FILNAM in the 1 
user's private file directory, pick up the address of the first track f 
of the file, and set the disk control hardware in motion to find this f 
track. While the apparatus is looking for the track, the .SEEK routine J 
returns to the calling program which may then make use of the seek time.f 
To read information from a file initialized by a call to the .SEEK f j 
routine, any number of calls to the .READK entry may be used in the 
following form: 

TSX .READK, 4 I 

* PZE FILNAM I 


The first or next n consecutive words will be read fro. the file 
specified by FIUUM. and stored in consecutive locations starting with 
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location A. If an attempt is made to read past the last word of the 
file, control is transferred to location X. When this occurs, the file 
being read is dropped out of the read status, and the buffers being used 
are available for other work. 

To terminate the reading of a file without having to read past the 
last word in the file, the following sequence is used: 

TSX .ENDRD.4 

PZE FILNAM 

For some applications, it is logically much simpler to treat each 
file as an addressable secondary memory. To facilitate this procedure, 
the next group of calls are alternatives to the above tape-like calls. 

The call : 

TSX . RELRW , 4 

PZE FILNAM 

PZE RWBUF 

will allow the specified file to be treated as an addressable secondary 
memory. Only one buffer should be specified, as double-buffering is 
not feasible in this case. This may be followed by calls to both .WRITE 
and . READK, using the calling sequences next described. 


The call: 


TSX .WRITE, 4 


PZE FILNAM, .RELADR 

PZE A, ,n 

will write the n words starting at core memory location A into the n 
words of the file starting at relative location RELADR. 

Similarly as in the .WRITE call, when the first parameter of a 

.READK call is 

PZE FILNAM, .RELADR 

and RELADR is non-zero, the reading process starts from that relative 
address of the file. 

When reading and/or writing is terminated, a call to .FILE or to 
.ENDED is given; when in the relative read-write mode, .FILE and 
.ENDRD are interchangeable. 
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The call : » 

TSX .CLEAR,! I 

*** FILNAM,, n g 

will create a file called FILNAM and of mode ***, and will write n zerosf 
into the file. 

To delete a file from a user's private file directory and thus 
free the tracks assigned to the file for other use by the same or by 
a different user the following sequence is provided: 

TSX .DLET2.4 

PZ2 FILNAM I 

The .DLETfi routine does not require any buffer storage, but it still 1 
must read every track of the file in order to find the addresses of all J 
the tracks used by this file and make the necessary changes in the track! 
usage table. Any file which has been placed in the read-only status § 
(either class 1 or 2) cannot be deleted in this way. 

The name or mode of a file may be changed by the following J 


sequence : 


.RENAM, 4 


*** NE’.VNAM, .FILNAM 

The .RENAM routine will replace the file name specified by FILNAM with 
the name specified by NEWNAM (two BCD words at NEWHAM and NETOAM+1) in 
the user's private file directory. The prefix code (***) determines the 
new mode for the file. A file which is in the class 1 read-only mode 
may be altered only by first changing its mode with a call to .RENAM. 

If it is desired to delete a file which is in the class 2 read-only 
mode, it is necessary to submit an edit card to the enter. 


The call : 


.RESET ,4 


will drop from active read or write status any of the user’s active 
files. Files which are reset from active write status will be lost. 
Temporary files reset from active read status will be deleted. 

To obtain a copy of the user file directory, the following se- 
quence is used: 
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TSX .FILDR.4 

PZE 0,0, BUFF 

The first track of the UFD is read into the 470 locations starting at 
bU FF. The decrement of the first word is zero if there is more than 
one track to the UFD; in this case the address and tag of this word con- 
tain information to be transmitted to the supervisor to obtain the next 
track ; this address and tag must be stored in the argument of the next 

call , as : 

TSX .FILDR, 4 

PZE **,**, BUFF2 

which will bring in the next track of the UFD. 

The decrement of the first word of the last (or only) track con- 
tains the number of words in this track not counting the first. The 
address of the second word contains the user’s total track count. The 
set of 4-word entries for each file follows, beginning with the third 


word . 


Information concerning a file may be obtained by the following 


sequence : 


.FSTAT.4 

FILNAM 


which will return the following information in the logical AC: 

*** '.VDCNT , , MODNO 

where *** specifies the mode. WDCNT is an estimated (maximum) word 
count based on the number of tracks, and MODNO is the logical module 

number . 

Error Procedure . The disk control subroutine will handle error 
conditions, unless the user adds another argument to any of the above 
calling sequences, specifying an error return. If this additional 
argument has a prefix of PZE, a diagnostic will be printed and control 
will be transferred to the specified location with an error code in the 
AC. If the error-return argument has a prefix MZE, the diagnostic will 
be suppressed but otherwise action: will be the same as with PZE. Note 
that an HTR instruction may not follow a disk-routine call as it will 
be interpreted as an error-return parameter. 
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The following is a list of possible error conditions with the 


corresponding error codes: 

Error Condition 

Illegal calling sequence 

Too many active files 

User not in Master File Directory 

Available space on module exhausted 

File not found 

Allotted track quota exhausted 


Error Code 




Disk Editor Control Cards 

Requests for off-line disk input and output and for other opera- 
^^■ons carried out at the time the disk is edited (loaded or dumped) 
are submitted to the Center Dispatching Area in the form of punched 
control cards. In the case of input, the input deck is submitted with 
the control card. 

The general format for control cards is as follows: starting in 
card column 1, a variable number of fields, each of variable length 
not exceeding 6 characters; fields are separated by commas, and 
reading of the card is terminated by a blank. In general the fields 
are : 

1 . Control word 

2 . Problem number 

3. Programmer number 

4. Primary file name 

5. Secondary (class) file name 
The following control words are used: 

Inpirt: This allows a file to be input from cards. The control 

card has the general format with a sixth field specifying the mode of 
the file, as a digit: 

» 0 = temporary 

1 = permanent 

2 = read only, class 1 

3 = read only , class 2 
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The deck immediately following the control card is put on the disk 
g. a single file. The input deck must be followed by a standard end-of- 
file card or a decimal card, blank in cols. l - 7, with *jlOF* in columns 
g-12 . Column binary and decimal cards may be mixed in the input deck. 

If the card is binary, 28 words are read; if decimal 14 words. When the 
end of the file is encountered, the file is added to the user's file 
directory . 

Files which have been dumped from the disk onto cards may be re- 
loaded using this control card. These dumped cards have a special 
prefix, 7, which is recognized by the editor program and causes the 
original file to be recreated. Such cards are sequenced, and they must 
be in order and form a complete set when reloaded. 

Edit: The control card has the same format as Input. This provides 

a means of loading a binary deck to form a core image of a program, 
which is then written as one record on the disk. The control card is 
followed by a column-binary record card for the deck; the record card 
has a prefix of 1 in the first word; the third word contains in the 
decrement the last address used by the program. The cards following 
must be absolute column -binary cards with correct check sums. The deck 
must be followed by an end-of-file card as described under Input. 

Print: The control card has the general format. The specified 

file is printed off-line. The file is assumed to be 14 words per line; 
a blank word is inserted before each line to ensure single spacing. If 
each line is preceded by a line mark, variable-length lines will be 
printed. The line mark has 7's in prefix and decrement, and the ad- 
dress contains the number of words in the line to follow. The first 
character of the first word following each line mark must be the print 
control character. 

Dpunch: This is the same as Print except that the files are 

punched off-line. Line-marked files are also recognized. 

Bpunch : The control card has the general format. The file is 

punched off-line, 28 words per card. No provision is made for 7-9 
punches or check sums, which are assumed to be included in the card 
image where required. 
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Delete: The control card has the general format, with an optional’#, 

sixth field. The specified file is deleted from the user’s file direcS 

tory. If the word "CARDS" appears in the sixth field, the file will 
dumped in the form of special cards. These are column-binary cards 1 

with a prefix of 7 in the first word of each card; instead of a loading 
address they have a sequence number. These cards may be reloaded using! 
Input . -J| 

7 punch : The control card has the general format. The file is ». 

dumped in the form of prefix-7 cards, as in Delete with the "CARDS" jg 

option. The file is not deleted. ,M 

Chmode : This allows the mode of a file to be changed. The control 

card has a sixth field specifying the new mode desired for the file 
(according to conventions specified under Input). If the new mode is if 
temporary, the user track count is adjusted. -* 

Copy: This control card causes a specified file assigned to one M 

user to be copied for another user so that each has an individual copy® 
The general format is used to specify where the file is going and what# 
it is to be called. Four additional fields specify the file that is ts 
be copied: problem number, programmer number, and two file names. ThJ| 
mode of the file is unchanged. 

Link : The format is similar to Copy. The specified file is not m 

copied, but is made accessible to the designated second user. More thalt; 
one link may be made to a given file. The linked file may be read by w 
all of the users who have access to it, but it may be altered only by M 
the primary user. Jl 
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t lonaj'-r 

llrec ]| CTSS LIBRARY 

ill be; 

!S 1 The library routines briefly described below are presently available 

>adin | t o console users. More detailed descriptions of usage, restrictions, 
USin f calling sequences, etc., may be found in short subroutine writeups for 
I each routine .which may be obtained from the Computation Center. For 
L * | the manner in which the CTSS library is made accessible see the 
P description of the load command, Chapter 7. 

:ontr< j| Blementary Function Routines 


AS IN, AC0S 


ATAN, ATN 


-e tha® 


EXP(1 


EXP (2 


EXP(3 


INDV, DPNV 


RANN0, SETU 


SIN, C0S 


Arc sine, arc cosine functions; floating-point 
argument . 

Arc tangent function; floating-point argument. 

Exponential function e X ; floating-point 
argument . 

Computes I J ; fixed-point arguments. 

Computes X K ; X floating-point, K fixed-point. 

Computes Y Z ; floating-point arguments. 

th 

Numerical solution of a system of N order 
non-linear simultaneous ordinary differential 
equations . 

Natural logarithm, floating-point argument. 

Generates a floating-point random number between 
0.0 and 1.0 with normal, rectangular distribution. 

Sine, cosine functions; floating-point radian 
argument . 
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SQRT , SQR 


i - : I ** 


TAN, C0T 


XSIMEQ, XDETRM 


.01300 


.01301 


.01311 


Library Versions of 


XINT, XF IX 


Square root; floating-point argument. 


Hyperbolic tangent; floating-point radian 
argument . 


Tangent, cotangent functions; floating-point radi^ 
argument. jit 

Solves matrix AX=B; computes value of determinant?! 


XMAX0 

XMAX1 


MIN LI 


Computes Y ; floating-point arguments (used by Ji 
Mad) . 1 

Computes X ; X floating-point, K fixed-point if 
(used by Mad) . If 

J f' 

Computes I ; fixed-point arguments (used by Mad)# 

Fortran Built-in Functions (used by Madtran) £ 

Truncation; floating-point argument. 

Fixed-point truncation; floating-point argument, ll 

Remaindering; floating-point. 

Remaindering; fixed-point. 

Maximum; fixed-point argument, floating-point f? 
function. § 

Maximum; floating-point argument, floating-point | 
function. | 

Maximum; fixed-point argument, fixed-point function. 
Maximum; floating-point argument, fixed-point .-ft 
function. § 

Minimum; fixed-point argument, floating-point I 

function. * 

$ 

Minimum; floating-point argument, floating 

point function. $ 
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Minimum; fixed-point argument, fixed-point function, 
Minimum; floating-point argument, fixed-point 
function . 


SIGN 

XSIGN 


Transfer of sign; floating-point arguments 
Transfer of sign; fixed-point arguments. 


dim 

XDIM 


Positive difference; floating-point arguments 
Positive difference; fixed-point arguments. 


Inpu t-Output Routines 

Using the CTSS library the user may read and write files on the 
disk. By subroutine calls he may: 1) use the disk-control subroutine 
entries directly as described in Chapter 5 (see also "Supervisor Entry 
Subroutine" below); 2) use a set of comparable routines suitable for 
Fortran and Mad programs, which automatically take care of format, 
buffering, and error conditions ("Heading and Writing the Disk, 
below); or 3) via Fortran or Mad Input-Output statements use routines 
which simulate tape usage on the disk ("Simulated Tape Usage ). The 
last method allows the convenience of the compiler I/O statements but 
with some loss of flexibility. For reading and writing the typewriter 
consoles the HEAD and PRINT statements should be used by Fortran and 
Mad programmers . 

A separate special library will be available for users who wish 
to read and write tape in accordance with the attach command. When 
this library is used, Fortran and Mad I/O statements will reference 
tape I/O subroutines; the usual set of I/O subroutines will be 
available . 


Reading and Writing the Disk . To create an output file on the 
disk the user specifies a file name consisting of two 6-character BCD 
names. Since the master disk-control routine uses core buffering 
(see Chapter 5), the user may, if he chooses, specify buffer space in 
his own program. Buffering may be either single or double, and for 
large-volume input or output there is a considerable increase in speed 
where double-buffering is provided for. Each buffer used for input to 
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or output from a single file must be a block of 470 words; for double 
buffering two 470-word blocks must be provided. The user may specify 
two, one, or no buffer areas; if he specifies none, a single buffer will 

automatically be assigned for a maximum of three simultaneously active § 
files. 

In calling the library subprogram ASSIGN, the user specifies the 
name to be given to the output file, and buffer space as desired. The 
file is placed in active write status. By calling DWRITE he may now 
write variable-length BCD records into the specified file. Several 
files may be active simultaneously (up to five, if adequate buffer 
space is provided), so each call to DWRITE must give the appropriate | 
file name among its arguments. Conversion to BCD is implicitly through! 
(I0H) and is controlled by a format specified as another argument in 1 
the subroutine call. The format conforms to Fortran specifications I 
(see CC-186-6) . After the file name and the format, subsequent argument! 
in the call to DWRITE constitute the output list. j| 

The length of an output record is determined by the format and the! 
output list. Each record is preceded by a one-word record mark con- 1 
taming 1 s in bits 0-17 and the number of words to follow in bits 18-35^ 

Successive calls to DWRITE will cause successive records to be 
written in the specified file. The file remains in active write status | 

The only limit on the size of a file is implicit in the user’s track j 
quota. % 

To conclude writing, to close out the file, drop it from active I 
status, and add it to his file directory, the user calls the subroutine! 
FILE specifying the appropriate file name as argument. When this is 
done the buffers assigned to that file are freed, whether provided by { 
the user's program or automatically assigned for him. If the user 
fails to call FILE, but calls EXIT at the end of his program, any files | 
still active will automatically be closed out for him. If he calls % 
neither FILE nor EXIT, output files which are still active will be lost 1 
To write a binary file, a call is given to ASSIGN just as for * 
BCD files; calls to B WRITE , specifying the file name and the output I 
list, cause binary output to be written. The output exactly follows the" 
argument list, and there are no record marks. 
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To read a file from the disk, the user first calls the subroutine 
jSEK, which is essentially similar to ASSIGN but puts the specified 
file in active read status. The same conventions apply to buffering. 

T0 read BCD records, DREAD is used, with argument requirements similar 
t0 those of DWRITE. Records are read according to the format specifica- 
tions. Two types of record format are allowed; in addition to the 
variable-length record described above, BCD files may be composed of 
fixed-length 14-word records without record marks (suitable for off-line 
card input or console input). 

To close out a file in active read status, a call to ENDRD, 

essentially similar to FILE, is given. 

Binary files may be read by BREAD, which is the converse of BWRITE . 
If it is desired to write additional records on an existing 
(inactive) file, this may be done by a call to the library subroutine 
APPEND. The arguments provided should be the same as those for 
ASSIGN; APPEND reopens the specified file and subsequent calls to 
DWRITE or BWRITE will cause additional records to be written following 

those already in the file. The conventions for writing and closing out 

S 

5| th e file are identical to those followed when writing a new file. 

If an end-of-file condition is encountered while reading a file, 

•1 the subroutine EOFXIT is called. This routine prints a diagnostic on 
•| the user’s console and calls EXIT. If other action is desired, the 
I user may substitute his own version of EOFXIT. 

f To dump a continuous block of core onto the disk as a file, the 

| user may call the library subroutine DSKDMP , specifying the name to be 
I given to the file, the location of the first word to be dumped, and 
I the number of words to be dumped. To load a continuous block of core 
from a file previously recorded on the disk, the routine DSKLOD is 
1 called, with a set of arguments similar to those for DSKDMP. 

To delete a file from his directory, the user may call the 

T 

library subroutine DELETE, specifying the name of the file, 
f To change the name of a file the subroutine RENAME is called, 

f specifying the old file name and the new one. To change the mode of a 
file the subroutine CHMODE is called, specifying the file name and the 
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desired new mode. Files of mode read-only, class 2 (see Chapter 5) 
may not be changed in this manner, nor may they be renamed. 

By way of illustration, a .Mad call to DWRITE, for example, might 

be : 

EXECUTE DWRITE . (NAMK1 , FMT1 , A(1)...A(N) ) 
where NAME1 and F.MT1 would be specified by 
VECTOR VALUES NAME1 = $ FIRST DATA$ 

VECTOR VALUES FMT1 = $(5F6.3)$ j| | Leg 

In Fortran, where the VECTOR VALUES facility is not available, the 
arguments might be specified as follows: 

CALL DWRITE (12H FIRST DATA , 7H(5F6 . 3 ) , A(l), A(2), etc. 
but for complicated formats, many calls, etc., this method is tedious. 

3 I 

Two routines are provided to simplify calls in Fortran; they are y I Le 

SETNAM and SETFMT. An example of a set of statements utilizing these 
could be : $£ 

DIMENSION NAME1 (2), FMT1 (10), BUFR1(470), BUFR2(470) 

CALL SETNAM (NAME1 , 12H FIRST DATA) t 

CALL SETFMT (FMT1 , 7H(5F6.3) ) 4 

CALL ASSIGN (NAME1 , BUFR1 , BUFR2) f. 

CALL DWRITE (NAME1 , FMTI , list ) 

etc. M 

‘b 

In addition to these subroutines, the master disk control subroutine 
entries may be used directly for input-output. Entries to the disk A; 
control subroutine may be made through the library (see below). 

Summary of Disk Input-Output Subroutines '< 


SEEK 

DSKDMP 

DREAD 

DSKLOD 

BREAD 

DELETE 

ENDRD 

SETFMT 

ASSIGN 

SETNAM 

DWRITE 

APPEND 

BWRITE 

EOFXIT 

FILE 



3r 


(FTB) and (BTB) , implicitly called by SEEK and ASSIGN, provide a 
directory of active files and associated buffers. 
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WRITE OUTPUT TAPE i 
END FILE i 
REWIND i 
BACKSPACE i 

REWIND TAPE i 
END OF FILE TAPE i 
BACKSPACE RECORD OF TAPE i 
BACKSPACE FILE OF TAPE i 


Simulated Tape Usag e. In order to allow the use of Fortran and 
standard input-output statements a set of library routines has been 

mi inr restrictions on the 

provided for simulation of tape usage. The major rest 

pseudo-tape usage are: 

1. only BCD routines are available; 

2. at most three "tape units" may be active (i.e., "positioned” 
for reading or writing) at one time. 

Legal Fortran statements are: 

READ 

READ INPUT TAPE i 
PUNCH 
PRINT 

Legal Mad statements are: 

READ FORMAT 
READ BCD TAPE i 
PUNCH FORMAT 
PRINT FORMAT 
WRITE BCD TAPE i 
Fap programs may call : 

(STH), (SCH), (SPH) 

(TSH) (CSH) 

(IOH), (FIL), (RTN) 

(BST) (EFT) , (RWT) 

Usage. For simplicity we will refer to Fortran statements, but 
Mad and Fap usage is essentially similar. The format of all the state- 
ments and subroutines listed above is unchanged; they may all be used 
in the traditional manner. For description of a record, see above 

"Reading and Writing the Disk." 

READ will read a record from the user's typewriter console. 

PRINT will type a record on the user's console. 

The first appearance of WRITE OUTPUT TAPE i will automatically 
cause the assigning of a disk file to the user, the file to be 
.. TflPE i" and of permanent mode. If a file of this name already 

exists in the user's directory, a „e. one will not be created but output 
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will be appended to whatever is already there. A variable-length record 
will be written in accordance with the format specified, and subsequent^; 
output statements designating this same logical unit will add records to 
the file. Until either a REWIND or END FILE statement is encountered 5 
or the program terminates in EXIT, the file ".TAPE. i" is in S 

active status. j: 

PUNCH is identical with WHITE OUTPUT TAPE 3. | 

The first appearance of READ INPUT TAPE i will cause the disk 
control routine to seek a disk file, assigned to the user, named 
".TAPE. i" and of permanent mode. If no such file is found, an 

error condition will result. If it is found, a fixed- or variable- 
length record will then be read and subsequent input statements 
designating the same logical unit will read subsequent records from the 
file. Until either a REWIND statement is encountered or the program 
terminates in EXIT, the file ".TAPE. i" is in active status. If 

an end-of-file condition is encountered, EOFXIT will be called. 

END FILE i will cause the file ".TAPE. i" to be dropped from 

active write status. If the designated file is inactive or if it is 
in active read status, no action will result. 

REWIND i will cause the file ".TAPE. i" to be dropped from 

active read or write status. If the designated file is inactive, no 
action will result. 

BACKSPACE i will have no effect, but a diagnostic will be printed 
at the console. 

When EXIT is called, all files still in active status will be 
closed out. If the program terminates without calling EXIT, any files 
still in active status will be lost. END FILE and REWIND are not 
normally necessary, provided the program terminates in EXIT and no 
more than three logical units are used. If more are required, or if a 
file is written and the same file read later in the program, it will be 
necessary to use REWIND or END FILE to drop a unit out of active 
s tatus . 
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Aux iliarv Subprograms for S imulated Tape Usage. 

— ' _ • J 


(IOH), (FIL), (RTN) 


.READ, .READL, .TAPBD, 
.PRINT, . COMNT , .TAPWR, 
PUNCH, .PNCHL 

(SPH), (STH), (SCH), 
(TSH) , (CSH) 

(SLI) 

(SLO) 

(EFT) 

(RWT) 

(BST) 

.BSF, .BSR, 

.EFT, . R'iVT 


Handles transmission and conversion of BCD 
data according to List and Format specifica- 
tions. implicitly called by Fortran READ, 
PRINT, READ INPUT TAPE, and WRITE OUTPUT TAPE 
Statements, by the analogous Mad statements, 
and by all calls to DREAD AND DWRITE . 

Mad BCD input-output routines, implicitly 
called by Mad I/O statements. 

Fortran BCD input-output routines, implicitly 
called by Fortran I/O statements. 

Provide list indexing for non-subscripted 
arrays in Fortran I/O statements; called 
implicitly . 

Tape manipulation routines, implicitly called 
by Fortran statements END FILE, REWIND, 
BACKSPACE . 

Tape manipulation routines implicitly called 
by Mad statements REWIND, END OF FILE, 
BACKSPACE . 


General Utility Programs 


.SETUP 


MOVIE) 


Sets up floating-point trap to (FPT) . 
Automatically compiled into Mad and Fortran 

programs . 

Contains the names, initial locations, entry 
points, and transfer vector length of all 
subprograms loaded into core by the load 
and use commands . 
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STOMAP 


Prints a storage map of all user subprograms £' 
loaded into core by the load and use commands.) 


(EXE) 


Decodes errors encountered in Fortran and Mad 
input-output library subroutines. Types out 
reason for error, saves machine conditions and 
transfers to RECOUP. % 


RECOUP 


Provides a skeleton subprogram to which (EXE) 

1 1 ‘i 

transfers after an input-output error; calls -- 
EXIT, with no restart permitted. The user mayj 
write his own RECOUP to allow for recovery | 

r: ; 

procedures. "S 


t. 

[■ S? 

. 

% ^ 

■ !• «l: 




(FPT) 


ERROR 


SAVMC 


Processes underflow and overflow in execution S 
of floating-point operations. Underflows are~J| 
set to zero, while overflows halt execution byj 

4 ' 

a call to ERROR. f 


Called by some math library subroutines in case 

ft 

of error. Prints diagnostic and trace of h 

logical path of program flow where standard £ 

error procedure is provided. After printing, || 

•« 

control returns to calling program. 

I 

$ 

Saves user’s machine conditions in a buffer f 

-M 

provided by the calling program. 


RSTMC 


Restores user’s machine conditions from a 
specified buffer, previously filled by SAVMC. 


LDUMP 


Called by some math library subroutines in case, 
of error. The library version of LDUMP calls 
EXIT. The user may write his own LDUMP to al- ^ 


low for recovery procedures. 
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dXIT, CLKOUT , 
SNDJOB, DUMP, 
PDUMP 


.03310, .03311 


Closes out any active disk files. Preserves 
machine conditions and goes to the supervisor 
in "dormant" status. If a start command 
follows, execution will be resumed at the 
location following the call to EXIT. 

Transfers control to the supervisor in "dead” 
status. Upon issuance of a new command, any 
active files not closed out prior to calling 
EXITM will be deleted. 

In compiled programs, finds the location 
where a variable is stored. 

In Mad, used to compute linear subscripts for 
two-dimensional arrays. 

In Mad, used to compute linear subscripts for 
arrays of more than two dimensions. 


LISTM 

IOSET 


For Mad list manipulation. 

Calls to IOSET are compiled into the object 
program during Madtran translations of 
Fortran input- output statements involving 
iterations . 


Supervi sor Entry Subroutine 

The following subroutine from the library may be used in place 
of direct calls to the supervisor. (e.g., the Fap instruction TSX 
5DEAD , 4 will effect a supervisor call to DEAD.) The entry names of 
this subprogram are: 


is ! 

DEAD 

.WRITE 

al- 1 

DORMNT 

.LOAD 

-4 

.RESET 

.DUMP 


. RENAM 

.APEND 
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. DLETE 
. ENDRD 
.FILE 


.ASIGN 
. READK 


SETFUL 

SETBCD 

WRFLX 


WRFLXA 


RDF LX 
RDFLXA 


There is no RDFLX in the supervisor. The routine RDFLXA reads a line 
from the console into the buffer specified along with the break 
character (usually carriage return); blanks are filled in to the right 
of the break character. The address of the AC contains N where the 
break character is the Nth character. The library routine RDFLX by 
using RDFLXA reads a line into the buffer specified with the break 
character stripped and all subsequent characters filled out with blanks, 
For both RDFLX and RDFLXA the maximum buffer length is 14 words. 





CHAPTER 7 

CONSOLE COMMANDS 

The following index refers to brief summaries which are given of 
the presently available commands. The command programs normally enter 
from the disk but in certain instances (e.g. start ) the command re- 
sides in the supervisor section of core memory. A block count is given 
to indicate the length of the commands. Each block is 256 1Q words 
long (128 blocks = 32,768 words), the increment for the protection and 
relocation registers. If a command is contained in the supervisor 
the block count is given as zero. 


Command Name 

Page 

attach 

86 

bkgrnd 

86 

brief 

81 

chball 

82 

chmode 

78 

comb in 

79 

(comment) 

69 

conf rm 

81 

cpu 

80 

delete 

78 

ditto 

82 

edit 

71 

fap 

72 

file 

71 

input 

70 

listf 

69 

load 

73 

login 

69 

logout 

69 

mad 

73 

madtrn 

73 
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memo 


82 



modify 

octlk 

octpat 

patch 

pm 

printf 

releas 

rename 

resume 

retrve 

rquest 

save 

split 

start 

status 

stopat 

time 

tra 

use 
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72 

86 

78 
75 
86 

79 
74 
78 
74 
86 
77 
81 
77 
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login a P 


olock count = 0 

^ = user problem number 
p = user programmer number 

Should be given at beginning of each user's session at a console. 
Clears time accounting records and logs out any previous user of the 
console. Prints out the contents of the supervisor message file, if any, 

deleting the file after printing. 

In the future an additional parameter may be required in order to 
afford greater security for the user. This will probably be in the form 
of a private code given separately; explicit instructions will be given 
by the login command if necessary . 


logout 


block count = 0 

Should be given at end of each user's console session. Copies 
user file directory to disk; prepares usage accounting records for the 
system. 


block count = 0 


a = arbitrary text treated as a comment, 


listf a f3 y 


block count = 4 


a) If a, P. 7 omitted, types out, in reverse chronological sequence, 
the list of all file names in the user's file with date-last-used, num- 
ber of tracks, and file mode. 
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m 

b) If a = rev," and g, y omitted, same as a) but in chronological y£ 
sequence. 

e) If a = file name, 0 = file class name, y omitted, types out a 
summary of information concerning the single file, 
d) If a = numeric month, £ = numeric day, y = last 2 digits of 
numeric year, same as a) but only those files filed on or before given 
date . 


input 


block count = 1 


I 

; 0 
f £J 


> rh 
u f-H, 


Initiates an automatic mode of input. The supervisor types out ~f 
line numbers which will be attached to the lines input by the user. The 
user types a card image per line, according to a format appropriate to f 
the programming language (see file command). Each line is processed 
by the input program. When in the automatic mode, a manual mode may -4 
be entered by giving an initial carriage return (for the 1014 Selectric \ 
console, the sequence: inquiry request, "w," inquiry release). In 
manual mode the supervisor types back the signal "MAN.” instead of a 

line number. The following conventions may be followed when in manual *6 
mode: 

a ) A line number (all numeric) followed by space or tab, 

followed by the desired line: this allows insertion and s 

correction of lines (cf. f lie command). If the line 

number is followed by tab, the first field is blank 
(cf. file ). 

b) DELETE, ^ where ^ and are previous line numbers; 
the lines from n^ through n^ will be deleted when the file 
command is issued; if is omitted, only n^ will be deleted. 

c) Initial carriage return or the corresponding 1014 sequence 
given above: the automatic mode will be resumed. 


d) SEQUENCE, n^ , n ^ where is a line number and n 2 is a 
line-number increment: the automatic mode is resumed 
starting at n , with subsequent numbers incremented by n g . 

If n is omitted the normal increment of 10 is retained. 

e) The command file a terminates the input mode and initiates 

the f ile command . 

If it is desired to leave the input mode without filing the input 
lines, the normal quit signal is given; input lines will be lost. 

edit a 0 

block count = 1 

a = title of file 
p = class of file 

The user is set in the automatic input mode with the designated 
file treated as initial input lines. The same conventions apply as 
to the input command. 

file a P 

block count = 7 

a = title to be given to file 
P = class of language used during input 

The created disk file will consist of the numbered input lines in 
sequence ; in the case of duplicate line numbers, the last version will 
be used. The line numbers will be written as right-adjusted sequence 
numbers in the corresponding card images of the file. 

For convenience the following editing conventions apply to input 

lines : 

a) a delete-message signal signifies the deletion of the line; 

b) a delete-character signal signifies the deletion of the 
previous character in the line. 
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The following formats apply: 

a) fap: symbol, tab, operation, tab, variable field and comment 

b) mad, madtrn : statement label, tab, statement. To place a 
character in the continuation column: statement label, tab, 
logical backspace, character, statement. 

c) data: 72 characters. 

If a file a, 0 already exists in the user's file directory this 
older file will be deleted and replaced by the a, 0 just created; a 
message is given to this effect. 

printf a 0 y 
block count = 5 

Types out file a, 0 starting at line number y. If y i s omitted, 
the initial line is assumed. If y does not match any line number in 
the file, printing commences at the first line number greater than y. 

Even though the identification field of a card image contains alphabetic 
characters, y represents only the numeric portion. 

If a, 0 is not in card-image form but written in the variable- 
length format, no line numbers will be printed. Printf will, if 
necessary, split a line which is too long for the console carriage. 

fap a 

block count = 61 

Causes the file designated as a. fap to be translated by the Fap 
translator (assembler). Files a,symtb and a,bss are added to the user's 
private files giving the symbol table and the relocatable binary form 
of the file, respectively. 

If the user's file directory already includes files a.symtb and 

a.bss these older files will be deleted and replaced by those created 
by this assembly. 

Reference: IBM Fap Reference Manual, Form J28-6098-1 
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sent. 


etic 


er's 

m 


mad OL 

block count = 43 

causes file a, .ad to be translated by the Mad translator (compiler). 
FU es a.dss and c—t are created giving the relocatadle dinary pro s ra. 

file and the translation summary file, respectively. 

If che user’s file directory already includes files a.hss and 

cmadtah these older files will be deleted and replaced by those 

created by this compilation. 

References: Mad Reference Manual 

Abbreviated Description, (forthcoming CC memo) 

I/O Format Specifications, CC 186 6 

madtrn a 
block count = 59 

Causes file a.madtrn (i.e.. a pseudo-Fortran II language file) 
to be edited into an equivalent file a.mad (added to the u 
translation of this file then occurs automatically as if the comman 

mad a had been given. 

If the user's file directory already includes file a, "ad this 
older file .ill he deleted and replaced by the file created by this 

translation . 

Reference on Madtran: CC -188-1 

Reference on Fortran: IBM Reference Manual, form C-28- 

Abbreviated Description, CC-164 5 
I/O Format Specifications, CC 186 6 


load 0^ 0t 2 


a 


block count = 9 

Causes the consecutive loading of files C^bss. An exception 
occurs if Ct - (libel, in which case a^.bss is searched as a library 
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file for all subprograms still missing. (There can be further library f 
files.) If after all cr have been processed there are still missing 
subprograms, the supervisor library file will be used in an attempt to 
complete loading. The only exception occurs if a. = (nlib) in which 
case the supervisor library is not used at the end of loading; if a 
subsequent a ± = (lib), the normal case is restored. If, after the 


1 

missing subprograms, 

a message will be typed of the form: 

i 

f 

1 

need p . . 

’ P k 


* 

1 • 

which may be followed by the use command. 



^“i a 2 a n 


t 

& 

block count = same as load 

J 

w 

This command is 

notifies the user of 


•4}. 

q 

H 

used whenever a load or previous use command 
an incomplete set of subprograms. Same a con 

jr. 

ventions as for load. 

i 

< 

i. ^ 

' pi 

start 








block count = 0 




Starts the program set up by the load and use commands or restarts 
a dormant program at the location just after the point .here the program 
entered the supervisor. 


save a 


block count = 0 


Creates file "a, saved,” consisting of the complete state of the 
user's last dormant program. 
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resume a P 1 • • • P R 
3 lock count = 0 

File "a, saved" is restored as the user’s program and is restarted 
,here it last left off. The parameters p. are entered into the usei 
command directory, which now contains: a P 1 • • • (i * e * > a re P laces 
resume and all arguments are shifted correspondingly). 


pm a 

block count = 0 

Produces post-mortem of user's last dormant program (loaded by 
the load command) according to the request specified by a. The 

following requests are permitted. 

Gives the stop location or ILC (1 line). 

Gives contents of locations 0,2 and 8 (1 line). 
Gives machine conditions and ILC (4 lines). 

Gives ILC and contents of two locations on either 
side of the stop (5 lines). 

Corresponds to "lights" plus "stop (9 lines). 

Gives the BSS loading table, with origin and 

entry of all subprograms loaded. 

Gives contents of the four initial locations of 

subprogram name (5 lines). 

loc mode direction 
1 2 

Gives contents of all locations from relative 
location loc x through loc 2 of subprogram "name," 
in the given mode and in the given direction. 
"Name" is (MAIN) for the main program. "Lo^ is 
assumed to be decimal; if the number is preceded 
by a slash, "/," it is taken as octal. "Mode" 
specifies the form of printed output, and may be: 
fix, flo, dec , oct, bed , or all . Direction 


a) 

pm ilc. 

b) 

pm traps. 

c) 

pm lights 

d) 

pm stop 

e) 

pm auto 

f) 

pm stomap 

g) 

pm name 

h) 

pm name loc 
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specifics the order of printing over the range 

(loc , loc ), and may be fwd or rev. If mode is 

omitted, all is assumed; if direction is omitted, 

fwd is assumed . Loc and loc may be replaced by 
1 z 

the single argument entire to cause printing of 
the entire subprogram. 


pm loc^ f ° C 2 m °de direction 


Gives contents of locations from absolute loca- 
tion loc through loc^. This is normally used 
for post-mortem of the common region. 


Reference: CC-167-6 


patch a 


block count = 0 


In 




ill 

fe?- 

| SP 

* up*** 

f K 


a = name of user subprogram loaded by load command 

Sets up a mode for entering patches to relative locations within 
a. If 0! is omitted, (MAIN) is assumed. In addition, three special 
patching modes may be used, i.e.: 

a) a = (abs) allows patches to absolute locations; 

b) a = (com) allows patches to relative locations in 
Common storage; 

c) a = (pat) allows patches to be entered into locations above 
the user’s current memory bound; this "patch space" is 
referenced by relative locations and is shared by all 
subprograms . 

After a response from the patch command, the user enters lines 


of the form 


P .7. 5,€ 


where : 


3 = octal address to be patched. This octal number may be im- 
mediately followed by a letter A, denoting an absolute location, C, 
denoting a location in Common, or P, denoting a location in the patch 


space . 






y — type of field which follows, i.e.: 

a) oct, octal word (used for instructions) 

b) flo, fixed on floating-point number (E or F notation) 

c) int, Fortran integer 

d) dec, Mad integer 

5 = number to be patched into ( 3 , according to format 7. 

€ = relocation bits if 7 = oct; two alphabetic characters, the 

first for the decrement and the second for the address. The 
characters are: 

A: absolute 

E: relocatable 

C : common 

P: patch space 

If 6 is omitted, AR is assumed. 

Successive 8 fields may be specified in any line, with the 

following € fields where necessary. 

Exit from the patch command is by the quit signal. 

tra a P 

block count = 0 

Where a is the name of a relocatable program loaded by the load 
command and p is a relative octal location in a, this command causes 
the setting up of a transfer to p. The transfer will be executed upon 
issuance of the start command. If a is omitted, the main program is 

assumed . 

stopat a P 
block count = 0 

Parameters a P as in tra. The instruction at p is replaced by a 
transfer; when this transfer is executed the original contents of P will 
be restored and the program will be placed in dormant status. The 
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s tart command may then be used to cause execution of the original 
(3 in a. If a is omitted, the main program is assumed. 



rename a 3 7 5 
block count = 1 

Changes the name of file cr,3 to 7 , 5 . The mode of the file is 
unchanged. If 5 is omitted, class 3 is preserved. 

chmode a 3 ra 

block count = same as rename 

Changes the mode of file a. 3 to that specified by m. The mode 
may be given as : 

T or 0 : temporary 

P or 1 : permanent 

R1 or 2 : read-only class 1 

R2 or 3 : read-only class 2 

A file in class R2 may not be altered by this command, nor by the 
rename command . 

delete a, 3, ... a 3 
11 n n 

block count = same as rename 

Deletes files CT . 3.^ from user's file directory. Files of class 
R1 or R2 may not be deleted by this command. A file of class R1 may be 
deleted only after its mode has been changed by chmode . 

split a 3 b. s — s b 
1 1 n -1 n 



sho 

the 

the 

an 

be 

the 

rerr 

err 

fil 

nut 

fo; 


co: 

bl 

is 

in 

If 

is 

is 

cc 

a 



block count = 9 

Splits the file a, 3 into n new files b, , 3 ... b ,3* Splitting 

In 


A 

c 

b 
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„ s , which 

of a,& is done after tho record sequence numbers s x n -l 

„ . Q _ Thp new files are appended to 

should be in ascending numeric orde . s "* " 

the user's file directory without resequencing. If any b. is , 

*. corresponding file is not added to the user's files. This provide, 

an easy way to extract subfiles from long master files. If b R is 

be it may be omitted. 

If any s. is or cannot be matched with a sequence number m 

the remaining'portion of the original file, this is an error; the 
remainder of file a.» is included .ith the last b t processed and a. 
error comment is given. If t.o of the s, are the same, only *h. firs 
file is created. Batching of sequence numbers is performed on the 

numeric portion only . 

I, file a.P cannot he found, the "need-use" convention is 
followed as in the load command . 


comb in s a (3 • • • ? n 


block count = 9 


combines the files into » single **1. «.S- "» he. file 

is resequenced, starting with sequence number s x 10 and with n 
incremented hy 10. The file is then added to the user's file directory. 
» s (a decimal number fro. 1-5 digits) is given as no r.sequencing 

U performed. If any of the 7± cannot he found, a list of those missing 
is typed out and the "us.” convention is fenced as in the load and 
commands . Ko ne« file is created unless the command is completed. ^ 
a "use" reentry to the comb in command specifies a file name as 
is as if the original file name did not appear. 


rquest c 0£ P • • • 

Permit, creation of control cards for revests to the dish editor. 
A file of special name and mode is created, consisting of control 
cards for those functions specified. At disk-edit time, this file .. 
b. read hy the editor mhich .ill process the requests and then delete 
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the file. If requests require special handling, the editor program 
will not service these but will create control cards which will be 
submitted to the Dispatcher. Requests will have the following para- 


oct: 


! bio 


meters : 


c = control word, e.g. Dpunch 
<2,0 = file name 

Subsequent parameters where needed, as: 
rquest delete a 0 cards 

To request that a file a,0 be restored from the history tapes 
next time the disk is loaded, the command has the form: 
rquest reload a 0 

and the rquest command will provide the necessary information 
concerning the pertinent history tape. 

The file created by this command (or added to by subsequent 
issuance of the command) has the name : 

REQUES T.FILE 

and is added to the user file directory. If the user wishes to change 
this file he must delete it and then reissue the desired commands. 


i U 

i sup 
is 

oct 

j 

blc 

rn; 

br: 

blc 


cpu a, ... a 
1 n 

block count = 0 

Gives user s current machine conditions as requested by a • As 
many of the following arguments may be given as desired, and in any 
order: 


moc 


coi 

bl 


AC 

entire contents of AC 

MQ 

contents 

of 

MQ 


SI 

contents 

of 

sense 

indicators 

IRS 

contents 

of 

index 

registers 

SLTS, 

contents 

of 

sense 

lights 


The requests are serviced one per line in the order given in the 
command. This command may be used during execution of absolute programs, 
command programs, etc. In the case of programs loaded by the load 
command, it gives the same information as pm. 


Th 

ti 

bl 

f r 

1 
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octlk m n 


! block count = 0 

j 

j Prints out contents of n locations starting at absolute location m. 

I If n exceeds the size, s, of the user's output buffer (internal to 
j supervisor) only the first s locations will be printed. The size of s 
is not fixed, but as a reasonable estimate n should not exceed 12. 

octpat m a b^ • • * a n b n 
block count = 0 

— ' Permits absolute patching into absolute locations beginning at 
m . a and b are octal left and right half-words, respectively. 

i i 

brief a 

block count = 0 

If a is omitted, the brief mode of console input is entered. This 
mode may be reset by repeating the command with a = OFF . 

conf rm a 
block count = 0 

If a is omitted, the confirmation mode of console input is entered 
This mode may be reset by repeating the command with a = OFF . 

time a 

block count = 0 

Causes the standard request for time-used messages to be changed 
ims ’ from "TIME" to the set of characters specified by a; a must be from 

1-6 printing characters. Time messages may then be obtained by the 




user’s typing an input message of C t followed by a carriage return. If 
d = OFF, the time-used facility will be suspended until another time 
command is given or until the user gives a logout command. 

chball a 

Allows for changing the type ball on the IBM 1014 or 1050 console. 
The designation of the desired ball is given by a (designations will be 
published later). The ball must be changed after "READY." is given. 

memo a 
modify a 0 
ditto a P 


§p>. |||« 

il 


r S 


block count = 37 

Use of memo generates a file a, memo; use of modify brings a user 
file a, memo into core for modification and refiling as 0,memo; if 0 is 
omitted, the old a, memo will be deleted and replaced by the modified 
version. Use of ditto generates a memorandum from file a, memo, 
beginning with page p; if p is omitted, the entire memorandum is 
produced; use of the p parameter provides a restart procedure. 

Memo, ditto , and modify are used with the typewriter to produce a 
memorandum. Textual information can be written, edited and manipulated 
by use of various control words . 

The method of entering the textual matter is similar to the method 
used by the input command. The memo program types a line number on the 
typewriter. The programmer then types the lines of text which he wishes 
to enter and strikes a carriage return. Memo will then type the next 
line number. If the programmer strikes an initial carriage return before 
the line of tejft would have been given, he enters the manual mode. 

This allows him to type his own line number followed by the text to be 
entered in that line. An initial carriage return ( or "if” for the IBM 
1014 or 1050) instead of a line number effects the re-entry to automatic 
typing of sequential line numbers. While operating in the manual mode, 


i iif a#***.-.* 


-■ > . ■'A*-; ftt 



the programmer may cause a previous line to be replaced or a new line 
to be inserted between previous lines, depending upon the line number 
which was typed. In particular, control word lines may be inserted 
among text lines. 

The modify command, which is essentially a restart of a previous 
memo command, brings the requested file into core memory. Line numbers 
are then typed sequentially as described in memo , except that the first 
number given is the line that closed the previous memo . Typed control 
words and line numbers are then accepted as in memo . If no p designation 
was given, the file a, memo will be replaced by the modified file. This 
new file will now be a, memo. 

The ditto command loads the requested file into core memory, strips 
the line numbers, and types a copy of the memo divided into pages. This 
1 process is guided and controlled by the control words interspersed in 
1 the text. The control words which may be used to alter the format or 
I facilitate correction are listed below; for ease in entering control 
words there is a set of abbreviated control signals which may be used 
as desired; these are listed also. A control word is recognized by a 
leading period. 


.EDIT FROM LINE XX 



,BD XX 

.END EDIT 



.EE 

.END MEMO 



.EM 

.DELETE LINE XX 



.DE XX 

.RESEQUENCE LINE NUMBERS 


.RE 

.COMMENT 



.CO 

.END COMMENT 



.EC 

.HEADER YYY 



.HE YYY... 

.BEGIN PAGE 



.BE 

.FOOTNOTE IN LINE XX 

AFTEFj YYY. . ,| 

.FO XX | YYY. . . | 

.DOUBLE SPACE 



.DO 

.SINGLE SPACE 



.SI 

.SPACE XX 



.SP XX 

.CHANGE TYPE RILL TO 

XX 


.CH XX 

.END FOOTNOTE 



• EF 

.EDIT PREPRINT FROM 

LINE 

XX TO LINE YY 

.ED PREPRI XX YY 
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a) .HEADER YYY. . . 

The 48 characters YYY . . . will be printed at the top of each page 
of the memo. The statement "Page xx of yy" will automatically be 
inserted to complete this header (or title) line appropriately for 
each page. Pages will not be numbered unless this control word is 
used. Normally this control word line should only occur once in a 
memorandum. 

b) .EDIT FROM LINE XX 

This control word line is not entered into the memorandum file. 

Memo and modify automatically switch to printing the line numbers which 
have previously been entered, instead of the consecutively incremented 
line numbers. This printing starts with line XX. The programmer can 
thus replace a series of lines without worrying about omitting any. 

The sequence will be interrupted by a new .EDIT FROM LINE XX control 
word or by the .END EDIT control word. 

c) .END EDIT 

This control word line, which is not entered into the memo file, 
causes the resumption of typing of new line numbers. 

d) .END MEMO 

The lines which have been entered will be filed in the user's file 
with the title given by the initial request for memo or modify. 

e) .DELETE LINE XX 

The line XX will be deleted, and no line will be entered into the 
memo file for this control word line. 

f) .RESEQUENCE LINE NUMBERS 

All the lines of the memorandum are assigned sequential line 
numbers, starting with 000100 and incrementing by 100's. A copy of the 
text (with line numbers) is printed when this process is complete. This 
control word facilitates additional correction and editing of texts 
which nay have had excessive corrections and insertions. The .END MEMO 
controj. word is -then assumed and the memorandum is filed as explained 
under d) . 

g) .COMMENT 

The lines of text which follow this control word line are considered 
to be notes or comments to the programmer. The .COMMENT control word 
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line will not appear in the finished Copy of the memorandum. The lines 
of notes following it will be printed on an initial page of the finished 
copy. These comments are extracted and printed at the beginning of the 
memorandum in spite of the fact that they had line sequence numbers 
inplying their position to be later. The signal to memo and modify 
that the comments are done is the .END COMMENT control word line. 

Other control word lines will not be recognized between .COMMENT and 
.END COMMENT. 

h) .END COMMENT 

This control word is the only means of indicating the end of a 
sequence of messages to the operator. 

i) .BEGIN PAGE 

The line following this control word will be positioned at the 
beginning of a page, (after a heading line, if present). 

j) .FOOTNOTE IN LINE XX AFTER [YYY...| 

The lines following this control word are considered the body of 
| the footnote. The footnote is terminated by the .END FOOTNOTE control 
| word or another .FOOTNOTE control word. The exact sequence of characters 
YYY . . . is found in line number XX and a footnote reference number is 
inserted in parentheses immediately following. Three or four blanks 
should be left in the correct position in line XX to permit this in- 
sertion without any overlapping. The body of the footnote will appear 
at the foot of the page containing line XX. Large footnotes may be 
extended to the next page . 

k) .DOUBLE SPACE 

A blank line will be inserted after each subsequent line of the 
memorandum. 

l) .SINGLE SPACE 

This control word causes a change in mode from double spacing to 
single spacing. 

m) .SPACE XX 

XX blank lines will be skipped before the next line of text is 
printed by the ditto program. 
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n) .CHANGE TYPE BALL TO XX 

This control word, useful only for the IBM Selectric typewriter, 
implies the intention to print one or more characters of the preceding 
line using a different type ball. When the finished form of the memo- 
randum is to be typed by ditto , a set of instructions to the operator 
will be printed on a preliminary page. A stop occurs after the 
affected line. The carriage should then be manually rotated back 2 lines. 
When the carriage return is struck, the printing of the line will continue 
assuming the type ball has been changed. It can be seen that blanks 
must be inserted carefully in the lines preceding the control word line 
and following the control word line to prevent over-printing. 

When typing with a non-BCD character set extra care must be taken 
not to strike the period position on the keyboard at the beginning of 
a line unless a control word line is intended. 

The memo may be continued using the new type ball until a change 
type ball control word is recognized. 

o) .END FOOTNOTE 

See the description of control word j). 

p) .EDIT PREPRINT FROM LINE XX TO LINE YY 

Lines XX to YY are printed after all pending editing, insertions, 
and deletions have been performed. 

Additional commands 

The following commands have not yet been completely defined, 
although their function has been described elsewhere in the text. A 
more precise definition of their usage will be published later. 


commur 

user 

basis 

he wi; 
magni* 
inter- 

-1 sxr 

contri 
s trai^ 
more - 

stater 

1 

i. 

Symbo: 
const: 
be as! 


a) 

attach 

see page 31 ; 


b) 

releas 

a command ordering the 

. in Coi 

release of a logical unit 



assigned by the attach 

comim 

command; 

c) 

bkgrnd 

see page 33 ; 


d) 

status 

see page 33 ; 

f apdb- 

e) 

retrve 

see page 29; 
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f) a command requesting an estimate of how long a job will take 
(see page 34) ; 

g) a command allowing the loading of absolute programs; 

h) command versions of three programs which have been run as 
experimental user subroutines, described below. 

plot 

The command plot is designed to give the user another means of 
communication with the computer via the plotters or scope. Once the 
user types plot, all further communication will be on a question-answer 
basis with the computer asking the questions. 

The user types two functions X and Y of a dependent variable t which 
he wishes to see plotted over a closed interval for t, the maximum 
magnitude attained by X and Y for a scaling option, and the desired 
interval for t; otherwise, the ranges of X, Y, and t are assumed to be 
-l^XTY^l and O^t^l . He also specifies a delta t, a constant, which 
controls the intervals at which the functions are evaluated (for a 
straight line approximation). Finally, he has the option of putting 
more than one plot on a single graph (perhaps for solving equations). 

The notation for the functions is similar to a Fortran arithmetic 
statement, with the following exceptions: 

1) mixed expressions are allowed; 

2) a**b has been replaced by pow (a,b). 

Symbols (first character always alphabetic) may be used to specify 
constants in these expressions; when their values are needed, they will 
be asked for. 

The plot program was written by Jay Martinson as a special project 
in Course 6.68; a more complete description will be given in a forth- 
coming CC memo. 



f apdbg 

This command will sent in operation a symbolic machine language 
debugging and control program, FAP DEBUG (similar to DDT, Flit, and 
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others), which will have been loaded automatically by the l^ad command. 
The program, in its currently available form, is capable of reading a 
SYMTB file and relocating the symbol values, in order to inform itself 
of the program symbols and thereby permit symbolic reference to memory 
locations. By typing requests to FAP DEBUG, the user can examine or 
change instructions or data, insert "break points" which will transfer 
back to FAP DEBUG when control reaches them, or begin execution of 
subprograms at any desired location. A full explanation of the present 
version of FAP DEBUG will be available in a forthcoming memo. 

Before transferring control to a subprogram, FAP DEBUG will request 
the supervisor (by a call to SETBRK) to transfer control back to FAP 
DEBUG if a "quit" signal is sent. After a "quit" signal, FAP DEBUG 
will set up to continue, if requested where execution was interrupted, 
as it now does after a break point is encountered. Thus, even if the 
program gets into a loop, it will be possible to return to FAP DEBUG. 

The FAP DEBUG program was written by Robert Campbell as a part of 
a bachelor's thesis. 


an IE 
black 
tion 
case . 


P 


sam 



A symbolic algebraic manipulation program has been developed, 
which will be put into command form. This program consists of a set 
of operations that the user may initiate from his typewriter. These 
operations include: substitution of variables; numeric evaluation; 
algebraic simplification; algebraic solution of equations; and certain 
bookkeeping and error correcting aids for minimizing the typing of 
large expressions. Further information may be obtained from the 
bachelor's thesis entitled "An Algebraic Manipulation Program for 
Time-Shared Computer Consoles," by Stanley Dunten. 
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APPENDIX A 


EXAMPLE OF A SESSION AT A CONSOLE 

The following is a reproduction of a short time-sharing session at 
an IBM 1014 Selectric typewriter console. Ordinarily the user types in 
black and the computer responds in red (or vice versa); in this illustra 
tion the user types in lower case and the computer responds in upper 
case . 



login ml416 1591 
WAIT, 

M1416 1591 LOGGED IN 5/27 1112.9 

READY. 

listf 5 20 63 
WAIT, 

10 FILES 20 TRACKS USED 
DATE NAME MODE 


5/20/63 

MAIN 

MAD 

p 

5/17/63 

DPFA SYMTB 

p 

5/17/63 

DPFA 

BSS 

p 

5/17/63 

DPFA 

FAP 

p 

READY. 





input 





WAIT, 





00010 


entry recoup 

00020 

recoup 

tra 

*+l 


00030 


cal 

1,4 


00040 


sto 

recoup 

00050 


trs 

2,4 


00060 


end 



00070 

IT 




MAN. 

40 

sta 

recoup 


NO. TRACKS 
15 
1 
1 
2 


MAN. file subr fap 
WAIT, 

READY, 
fap subr 
WAIT, 

O 00005 .000 00 4 00002 

00006 FIRST LOCATION NOT USED 
FAILED 
READY. 


TRS 


2,4 


00000050 
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edit subr fap 
WAIT, 

00070 it 

MAN. 50 tra 2,4 

MAN. file subr fap 
WAIT, 

OLD FILli DELL TED . 

READY. 

printf subr fap 
WAIT, 


00010 

ENTRY 

RECOUP 

00020 

RECOUP TRA 

*4-1 

00030 

CAL 

1.4 

00040 

STA 

RECOUP 

00050 

TRA 

2,4 

00060 

END 



READY . 
fap subr 
WAIT, 

00006 FIRST LOCATION NOT USED 

READY. 

mad main 

WAIT, 

LENGTH 02076, T.V. SIZE 00020, ENTRY 00735 
READY. 

load main subr 
WAIT, 

NEED DPSUBR 

READY, 
use dpfa 
WAIT, 

READY. 

start 

WAIT, 

FILE TEST DATA NOT FOUND. 

NO ERROR RETURN SPECIFIED 
READY, 
pm lights 
WAIT, 

PROG SEEK ST0P= 112 REL., 14273 ABS . TSX 007400414161 
AC = 000014000000, S =0 , Q =0 MQ = 000010000000 SI = 400004000000 
1X1 = 2 1X2 = 14 1X4 = 63505 SENSE LIGHTS ON 4 

FPT ON , DCT OFF, ACOF OFF 
READY . 
save may27 
WAIT, 

READY. 



1 istf 
WAIT, 

16 FILES 66 TRACKS USED 
DATE NAME MODE NO. TRACKS 

5/27/63 M1Y27 SAVED P 31 

5/27/63 MAIN BSS P 5 

5/27/63 MAIN MADTAB tt QUIT, 

READY. 

logout 

WAIT, 

M1416 1591 LOGGED OUT 5/27 1140.3 

TOTAL TIME USED= 01.6 MIN. 

READY. 
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APPENDIX B 


CURRENT RESTRICTIONS 


The list given below specifies those features described in the text 
which at present writing are incompletely implemented. It was the in- 
tent in writing this book to present as complete as possible a picture 
of the scope of CTSS . During the programming of the system not all 
features, of course, can be considered of equal importance. The 
facilities listed here are being programmed as we go to press; users 
of CTSS can obtain from the Computation Center periodic notification 
of their availability. 

7320 drum (to be added August 1963) - p. 3. 

Time-used messages - p. 15 and p. 81. 

Simulation of interval timer clock - p. 15. 

Setting of arbitrary console break characters - p. 16. 

Character mode (12-bit) switch - p. 17 and p. 43. 

Brief and confirmation modes - p. 22 and p. 81. 

Interconsole messages - p. 22. 

Common files for programmers with same problem number - p. 24. 

Automatic extension of track quota (available soon) - p. 25. 

Generation from console of disk ed.vtor control cards (available 
soon) - p. 25-26 and p. 79. 

History tape procedure - p.27-30 and p. 86. 

Supervisor messages and automatic cutoff (available soon) - p. 30. 
Attachment of input-output units - p. 31 and p. 86. 

Dataphone attachment - p. 32. 

Modification of command parameter list (available soon) - p. 33. 
Console-inititated background - p. 33 and p. 86. 

Estimation of completion time - p. 34 

Link disk editor control function (available soon) - p. 54. 

Library of subprograms for use of attached tapes - p. 57. 

Library routines SAVMC and RSTMC (available soon) - p. 64. 




Commands : 


chball - p. 82. 
cpu - p. 80. 

memo, modify and ditto (available soon) - p. 82 
Macro facility in fap command - p. 72. 
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memoranda which set down, sometimes in greater detail than is given in CC 

the text, the specifications for certain aspects of CTSS. These 
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since they were preliminary ones, have become obsolete. 
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